Date: Mon, 23 Nov 1998 18:12:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: DBECK@ludens.elte.hu (David Beck) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: SYSV Semaphores & mmap problems Message-ID: <199811231812.LAA18985@usr02.primenet.com> In-Reply-To: <Pine.VMS.3.91-vms-b4.981123093440.30337A-100000@ludens.elte.hu> from "David Beck" at Nov 23, 98 09:40:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Use fcntl(2) based locks. > > > > Preferrably against an mmap'ed file as the shared memory region > > instead of a SYSV shared memory region, to avoid using up kernel > > virtual address space. > > > > Alternately, someone need to write a non-blocking version of > > the system call and implement call conversion in a (new) libipc_r. > > > > Thank you. The sysv semaphore seems fairly slow on other systems, anyway. > Do you know is fcnt faster ? I haven't explictly timed them in FreeBSD, but I expect that fcntl is faster. I *did* time them on UnixWare, SunOS, AIX, and Solaris, and fcntl() was faster on those platforms by a significant amount; the AIX system used had a unified VM model, so I expect it to be predictive of FreeBSD. The semantics of SYSV semaphores are such that they expect to be in regions such that the calls are required to maintain the cache coherency on a split VM and buffer cache. They are built for function, not for speed. I do know that anonymous shared memory segments, such as those which arise from SYSV shared memory are vastly faster than those that arise from mmap'ing a file. This is because John Dyson did a lot of work to make the SYSV SHM faster for the Oracle database, which uses SYSV SHM. The work is directly applicable to mmap, as well, but mmap has an implied write-though caching to the backing object, making it somewhat slower as a result of needing to write through. You can actually get mmap'ed memory that is as fast as SYSV SHM by mmap'ing anonymous memory off of fd -1, or off of an fd that is attached to /dev/zero. The problem with this is that there is no way to rendezvous this memory between processes, unless they are all descendents of the original process that did the mapping. BSD really needs to fix this deficiency, probably by adding a method, similar to that for passing fd's, to pass region mappings to other processes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811231812.LAA18985>