Date: Tue, 24 Feb 2009 00:09:42 -0800 From: Garrett Cooper <yanefbsd@gmail.com> To: Bill Moran <wmoran@potentialtech.com> Cc: Kirk Strauser <kirk@strauser.com>, freebsd-hackers@freebsd.org, Christian Peron <csjp@freebsd.org>, "Brian A. Seklecki" <lavalamp@spiritual-machines.org> Subject: Re: shmmax tops out at 2G? Message-ID: <7d6fde3d0902240009q77e3be85n54c17f7404bc446b@mail.gmail.com> In-Reply-To: <20090223151611.af79586c.wmoran@potentialtech.com> References: <1235404207.31655.2085.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20090223190828.GA34866@jnz.sqrt.ca> <78AACD88-3F94-4B39-9122-9C4199DFFDBA@gmail.com> <20090223201217.GA35374@jnz.sqrt.ca> <20090223151611.af79586c.wmoran@potentialtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 23, 2009 at 12:16 PM, Bill Moran <wmoran@potentialtech.com> wro=
te:
> In response to Christian Peron <csjp@freebsd.org>:
>
>> On Mon, Feb 23, 2009 at 11:58:09AM -0800, Garrett Cooper wrote:
>> [..]
>> >
>> > =A0 =A0 Why isn't the field an unsigned int / size_t? I don't see much=
value
>> > in having the size be signed...
>>
>> No idea :) This code long predates me.
>
> It's that way because the original Sun spec for the API said so.
>
> It makes little sense to change it just to unsigned. =A0The additional 2G
> it would give doesn't really solve the tuning problem on a 64G system.
> This is simply a spec that has become outdated by modern hardware.
Ah, but an unsigned integer on a 64-bit system supports that kind of
precision ;). Or are you saying you're crazy enough to run PAE mode
with that much RAM 0-o?
Then again the bug filer's statement doesn't make sense given the data
-- there must be a int32_t used somewhere that's mucking up the
system. Trying to compile the test app with -Wall, this is what I see:
[gcooper@optimus ~]$ gcc -Wall -o test4 test4.c
test4.c: In function 'main':
test4.c:11: warning: 'return' with no value, in function returning non-void
test4.c:13: warning: format '%zd' expects type 'signed size_t', but
argument 2 has type 'int'
#include <stdio.h>
#include <sys/shm.h>
int main() {
size_t size =3D 2*1024*1024*1024l - 4096;
int segid;
printf("Requested: %zd\n", size);
segid =3D shmget(234, size, IPC_CREAT);
if(segid =3D=3D -1) {
perror("Died");
return;
}
printf("SHM ID : %zd\n", segid);
}
So I'm not 100% sure that this issue isn't a coding error, or the
sample app is just incorrect... When the error comes back though from
the perror, it returns EINVALID, not ENOMEM or something similar to
that. Not sure if it's because the value is truly invalid, or if it's
just a bad return code.
My 2 cents...
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d0902240009q77e3be85n54c17f7404bc446b>