sgi_use_anyaddr(1) sgi_use_anyaddr(1)
sgi_use_anyaddr - disable reserved range for auto-placed mappings
sgi_use_anyaddr command [arguments]
sgi_use_anyaddr executes command with the reserved range of the virtual
address space (from 0x30000000 to 0x40000000) disabled. Normally, the
kernel does not auto-place mappings made by mmap(2) and shmat(2) in the
reserved range. By disabling the reserved range with sgi_use_anyaddr, the
kernel is permitted to use any available virtual address for mapping
requests made by command. sgi_use_anyaddr is implemented by invoking
syssgi(2) with request parameter SGI_UNSUPPORTED_MAP_RESERVED_RANGE and
then performing an exec of command. The effect of this option is the same
as if MAP_SGI_ANYADDR and SHM_SGI_ANYADDR were added to all future calls
to mmap(2) and shmat(2) respectively by command. Note that this syssgi
option is inherited across fork and exec, so command and all its
descendants will be affected by this.
As described in mmap(2), the kernel chooses a virtual address for a new
mapping created by mmap(2) or shmat(2) when zero is passed as the attach
address. When the kernel auto-places a mapping in this manner, it is
guaranteed that it will not place the mapping in the reserved range. The
only mappings that can be placed in the reserved range are those where
the user explicitly specifies an attach address that is in the reserved
range.
The reserved range was originally created in the earlier 90's by a
MIPS/UNIX standards body at the request of application writers. The
application writers wanted a portion of the virtual address space where
they could be assured they could place their own mappings via mmap(2) and
shmat(2) without the risk of overlapping other mappings placed by the
kernel. A 256 MB region from 0x30000000 to 0x40000000 was reserved for
use by applications to use by specifying an explicit attach address with
mmap(2) or shmat(2). It is guaranteed the kernel will never auto-place a
mapping in this range when zero is passed as the attach address to
mmap(2) and shmat(2) because this range has been reserved for
applications that specify explicit attach addresses in this range.
At the time the reserved range was created, applications were still
relatively small by today's standards, so having this 256 MB hole in the
middle of the 2 GB user virtual address space was not an issue.
Application program size has grown substantially over the years and some
applications find they can no longer easily fit in the 2 GB address space
available when running in 32-bit mode. Having the reserved range take
away 256 MB makes it difficult for some applications to allocate the
memory space they require on 32-bit systems. This command, the
SGI_UNSUPPORTED_MAP_RESERVED_RANGE syssgi(2) option, the MAP_SGI_ANYADDR
flag to mmap(2), and the SHM_SGI_ANYADDR flag to shmat(2) together allow
the application to control when the reserved range is used so
applications which so choose may disable it. For compatibility, the
Page 1
sgi_use_anyaddr(1) sgi_use_anyaddr(1)
reserved range is normally enabled.
The reserved range is in effect for 64-bit applications as well, but
since the virtual address space is so large for these it is rarely an
issue. In general, 64-bit applications do not need to be concerned with
these new flags and options to control the reserved range.
/usr/lib/locale/locale<b>/LC_MESSAGES/uxue
language-specific message file [See LANG on environ(5).]
mmap(2), shmat(2). syssgi(2).
Some existing applications are dependent on the reserved range being
honored by the kernel. Using this command to disable the reserved range
for a command that requires it may cause it to fail, dump core, or
otherwise execute incorrectly. This applies to any other programs the
command may run via fork/exec since the option is inherited. Therefore,
this command and the syssgi(2) option must be used with extreme care. It
should only be used with programs the user is certain are not dependent
on the reserved range. The effect this command may have on applications
that are in some way dependent on the reserved range is strictly
unsupported by SGI.
PPPPaaaaggggeeee 2222 [ Back ]
|
