From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 13 18:34:44 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BD9616A415 for ; Wed, 13 Dec 2006 18:34:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail24.syd.optusnet.com.au (mail24.syd.optusnet.com.au [211.29.133.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id C735143C9F for ; Wed, 13 Dec 2006 18:33:12 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c58-107-94-118.belrs4.nsw.optusnet.com.au [58.107.94.118]) by mail24.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id kBDIYWUH027078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Dec 2006 05:34:37 +1100 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id kBDIYWrC003370; Thu, 14 Dec 2006 05:34:32 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id kBDIYVUT003369; Thu, 14 Dec 2006 05:34:31 +1100 (EST) (envelope-from peter) Date: Thu, 14 Dec 2006 05:34:31 +1100 From: Peter Jeremy To: Bill Moran Message-ID: <20061213183431.GC888@turion.vk2pj.dyndns.org> References: <20061212121714.a3fbb61b.wmoran@collaborativefusion.com> <20061213105021.c7d5b274.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <20061213105021.c7d5b274.wmoran@collaborativefusion.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: hackers@freebsd.org, Kris Kennaway 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: Wed, 13 Dec 2006 18:34:44 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote: >In response to Bill Moran : >> sysctl kern.ipc.shmmax=3D2200000000 >> kern.ipc.shmmax: 2100000000 -> -2094967296 >>=20 >> 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). >>=20 >> 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. --=20 Peter Jeremy --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgEe3/opHv/APuIcRAvUTAKC3tHgy0OwHSRh6FRow+GOTaJa16wCeIpEp UyAcTb7EtlLE/NBBvfmR9Xo= =qtGY -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko--