Re: Anything wrong with x86_64 and SYSV shared memory allocation?
Re: Anything wrong with x86_64 and SYSV shared memory allocation?
- Subject: Re: Anything wrong with x86_64 and SYSV shared memory allocation?
- From: Terry Lambert <email@hidden>
- Date: Tue, 24 Apr 2007 05:00:07 -0700
On Apr 23, 2007, at 7:33 AM, Kevin Murphy wrote:
I've previously posted to darwin-dev and darwin-x86 lists with no
response.
Whenever I try to use shmem to allocate SYSV shared memory on an
XServe
Quad Xeon (OS X 10.4.9, latest XCode) using the "-arch x86_64"
compiler
switch, I get ENOMEM returned. There's plenty of SYSV memory
allocated via sysctl.conf, and the same code works fine with "-arch
i386" (or "-arch ppc64" on a G5). This box has 16GB RAM, although
that is presumably irrelevant.
Anything I need to know?
I double-checked the result with a SYSV shared memory demo program
(google for shared-mem.c).
What I'm actually trying to do is compile 64-bit PostgreSQL, which
compiles fine using "-arch x86_64" in CFLAGS, but it fails its
regression tests because it can't allocate memory with shmget
(ENOMEM is returned). The 32-bit PostgreSQL compiles and works fine.
It's trying to allocate the memory in the lower 4G of the process
virtual address space, and unless you turn off the 4G page 0 mapping
(or munamp() it after you're running but before you attempt to
allocate shared memory), it's not going to see any free address space
available. This is a consequence of a tools change that made that
memory unavailable under normal circumstances, to avoid the TLB
flushes on a CR3 reload that's necesswary if program data and the
kernel occupy the same virtual address ranges. This is a difference
between the PPC 64 bit and Intel 64 bit implementations (but PPC will
likely follow eventually).
You should also consider using shm_open() instead; the most recent
patches (February of this year) for this seem to be here:
<http://www.mail-archive.com/email@hidden/
msg14808.html>
And since POSIX shared memory isn't as limited as System V shared
memory, there's a nice performance win, as well (you will still need
to map it below the 4G mark, however).
Note that due to limitations in the Postgres implementation, you will
also not be able to mix 32 and 64 bit clients of the shared memory
segment, given that Size is typedef'ed to size_t, and therefore that's
8 bytes on LP64 and 4 bytes on ILP32 (this is one reason why using
sized types is just a good idea).
Oh, and Chris also suggests using System V semaphores instead of POSIX
semaphores in Postgres, to avoid the fd pressure (binary backward
compatibility is a bear in some places):
*** /Users/chrismarcellino/postgresql-8.2.2/src/template/darwin Fri
Mar 10 20:38:40 2006
--- /Users/chrismarcellino/darwin Wed Feb 7 13:56:01 2007
***************
*** 4,8 ****
# (Note: on OS X before 10.2, you might need -traditional-cpp
instead)
CC="$CC -no-cpp-precomp"
! # Select appropriate semaphore support
! USE_NAMED_POSIX_SEMAPHORES=1
--- 4,16 ----
# (Note: on OS X before 10.2, you might need -traditional-cpp
instead)
CC="$CC -no-cpp-precomp"
! # Select appropriate semaphore support. Darwin 6.0 (Mac OS X 10.2)
and higher
! # support System V semaphores for better peformance.
! case $host_os in
! darwin[015].*)
! USE_NAMED_POSIX_SEMAPHORES=1
! ;;
! *)
! USE_SYSV_SEMAPHORES=1
! ;;
! esac
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden