site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Anything I need to know? I double-checked the result with a SYSV shared memory demo program (google for shared-mem.c). *** /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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. 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/pgsql-patches@postgresql.org/ 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): This email sent to site_archiver@lists.apple.com