From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 24 08:09:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D181065670 for ; Tue, 24 Feb 2009 08:09:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0EB8FC12 for ; Tue, 24 Feb 2009 08:09:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so875139ywt.13 for ; Tue, 24 Feb 2009 00:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SxdbHxYtQL5NKr1lq8YD1lyPLIiu83voEyo90jR6ZzE=; b=F/4NNESeZIB4+cKhnqZ4AgaSASOrDKjWSLLYI/yK3JcvEew6XOYxVlIo4yYd/ivh0C 4+g8vfDwzLmjBIBpeDhWrwA3rkGXzRW8MzsvDiImnZE529Y7inGY67leeumV7CC2RLPP ffoB/UcTBFKQ2OYfN/KCcVSqiL87VR1eICHEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rh1swF48uQdcd2qxT4jryzIXqgPQN3Xq9yz6/3VpntBtrYgATq3Y2PDTRupkmhcYSS TeWtiDwlWL5r2WkZTxz+BrXzqucEiPPJquUHPz5KrTNoe5P5RoKqbdRCxVbuZasM0XVE lb4135fdgJtHmt2N0bW3cus+twcbDBU0mgGkY= MIME-Version: 1.0 Received: by 10.90.69.15 with SMTP id r15mr2025042aga.94.1235462982502; Tue, 24 Feb 2009 00:09:42 -0800 (PST) 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> Date: Tue, 24 Feb 2009 00:09:42 -0800 Message-ID: <7d6fde3d0902240009q77e3be85n54c17f7404bc446b@mail.gmail.com> From: Garrett Cooper To: Bill Moran Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kirk Strauser , freebsd-hackers@freebsd.org, Christian Peron , "Brian A. Seklecki" Subject: Re: shmmax tops out at 2G? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 08:09:43 -0000 On Mon, Feb 23, 2009 at 12:16 PM, Bill Moran wro= te: > In response to Christian Peron : > >> 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 #include 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