Date: Thu, 14 Dec 2006 05:34:31 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Bill Moran <wmoran@collaborativefusion.com> Cc: hackers@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: shmmax tops out at 2G? Message-ID: <20061213183431.GC888@turion.vk2pj.dyndns.org> In-Reply-To: <20061213105021.c7d5b274.wmoran@collaborativefusion.com> References: <20061212121714.a3fbb61b.wmoran@collaborativefusion.com> <20061213105021.c7d5b274.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote:
>In response to Bill Moran <wmoran@collaborativefusion.com>:
>> sysctl kern.ipc.shmmax=2200000000
>> kern.ipc.shmmax: 2100000000 -> -2094967296
>>
>> Looks like an unsigned 32-bit int. That doesn't seem to scale as well as
>> would be expected on 64-bit arch (or PAE for that matter).
>>
>> Is this a mistake, or intentional? I'm working with some big memory
>> systems, and I sure would like to allocate more than 2G for PostgreSQL
>> to use ...
I thought POSIX specified 'int' but I may be mis-remembering. Tru64
uses int (and 2GB max) whilst Solaris allows 64-bit values.
Logically, shm_segsz and shm{min,max} should be intptr_t, shmall is
less clear but probably should be similar.
>int shmget(key_t, size_t, int);
>
>I appears as if those values should have been size_t all along. I'm
>_assuming_ that the return value is an identifier and not a memory
>address, which is what the docs seem to imply.
shmget() returns an "id" that uniquely refers to a shared memory
segment (stupidly designed SysV IPC namespace) and shmat() takes
the "id" and returns the address.
>So, my first thought is that all the int values in those structures
>should be changed to size_t. If I understand the use of that type
>correctly, it should always be the native word size on the architecture,
I believe intptr_t is more logical - an integer size that is the
same size as a pointer. Unfortunately, as I mentioned above, some
of this is specified in "standards" and logic is usually only present
by accident in such documents.
>but will that make this work for PAE as well, or should those be
>changed to uint64_t so they're 8 bits wide on all archs?
PAE is kernel only - userland still sees only 32 bits. (You can
fit more RAM into the box, but each process is still limited to
4GB - KVM size). Don't unnecessarily use [u]int64_t as it is
comparatively inefficient on 32-bit architectures.
I know Oracle (at least) avoids the problem on Tru64 by using
multiple SHM segments to allow SGA exceeding 2GB.
--
Peter Jeremy
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFFgEe3/opHv/APuIcRAvUTAKC3tHgy0OwHSRh6FRow+GOTaJa16wCeIpEp
UyAcTb7EtlLE/NBBvfmR9Xo=
=qtGY
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061213183431.GC888>