The issue was:
In our project we have a group of applications which all use the same
big datafile which they load into memory. It is possible to
use mmap to make the applications use the same memory, but the problem
with our datafile is that it contains pointers.
If there are pointers in the datafile which mmap loades, mmap must load
the file into memory at the same location for all the applications
which use the datafile. This is only possible with the options mmap:
MAP_SHARDED | MAP_FIXED
The questions are:
1. Is it safe to use mmap with MAP_FIXED and which addresses
can be used?
2. If not, do you know of any other way to save memory with a
datafile containing pointers.
<9510021855.AA04289@nova.netapp.com> guy@netapp.com (Guy Harris) writes:
> Different hardware may allow different regions to be mapped; some older
> Suns have MMUs that don't allow certain segments of the address space to
> be mapped.
>
> SunOS (4.x or 5.x, 4.1.x being the OS component of Solaris 1.y, and 5.x
> being the OS component of Solaris 2.x) puts various kernel stuff at the
> top of the address space; different releases may use different sections
of the top of the address space, and even the same release may use
> different sections on different hardware (for example, 4.1.3, on Sun-4m
> machines, takes everything from 0xF0000000 to 0xFFFFFFFF - it may not
> use it all, but it prevents any of it from being used by user-mode stuff
> - while, on Sun-4c machines, it takes everyhing from 0xF8000000 to
> 0xFFFFFFFF).
>
> In addition, the run-time linker "mmap()"s in any shared libraries your
> process uses, starting below the stack limit; under different releases
> of the OS, the shared libraries in question may have different sizes (or
> may themselves cause different sets of *other* shared libraries to be
> included), so the amount of space at the top of the user-mode address
> space that's available for "mmap()"ping by the program may differ. (And
> changing the stack limit will also change that....)
>
<199510021925.PAA25258@freenet.carleton.ca> aa735@freenet.carleton.ca
(Duncan MacGregor) writes:
> The best solution is to call 'mmap()' the first time with the MAP_SHARED
> option only. The pointer returned, however, may be used in *subsequent*
> calls to 'mmap()' with the MAP_FIXED option included. Since 'mmap()' has
> already returned it once, there should be no difficulty in re-using it in
> other processes -- though this is not foolproof.
This will not work as mmap returns virual memory addresses and one virtual
address which is ok for one process may not be ok for another process.
<44o9u2$1ag@gatekeeper.alcatel.no> barts@Eng.Sun.COM writes:
> Imbedding pointers in data files is quite risky. You can (and will) run into
> the following problems:
>
> 1) The address space layout of different SPARC platforms can vary. For
> example,
> old sun4c machines have a large hole in the virtual address space which
> isn't
> present on later machines, and newer machines such as UltraSparc may have
> layouts that don't work on older machines.
>
> 2) The addition of various shared libraries in subsequent releases of either
> your
> application or Solaris can cause the available address space
change, breaking
> your
> application.
>
> 3) Persistent data files that contain pointers will be difficult to
use in 64
> bit programs.
>
>
> If you're still in the design stages, using an index from the
beginning of the
> file is
> a much preferred solution, and is relatively easy to implement with
macros.
The normal layout of the virtual memory on a machine is that the code
segment starts at low memory addresses, the data segment starts above
the code segment, the heap start above the data segment and that the
stack groves to lower addresses from the almost the top of the virtual
address space.
I therefore choose to put the start of the shared data at a high address
0x2000000 (about 500 Mbyte high). This should be safe for most machines
I think as the virtual address space is 4 Gbyte.
--vvvvvvvvv ---------------------------------------------------------------- vvvvvvv Harald Nordvoll phone: +47 22637593 vvvvv Alcatel Telecom Norway AS mail: Pb. 310 Okern, N-0511 Oslo vvv Oslo, Norway e-mail: harald.nordvoll@alcatel.no v --------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:34 CDT