Date: Wed, 10 Feb 1999 17:24:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: dillon@apollo.backplane.com, tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902101724.KAA13526@usr07.primenet.com> In-Reply-To: <199902092341.PAA09407@implode.root.com> from "David Greenman" at Feb 9, 99 03:41:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >:The overall size of the shared memory segment is limited to that > >: which can fit in the kernels virtual address space; this > >: artificially restricts the maximum size. > > That isn't true and hasn't been true for several years in FreeBSD. Are you sure? >From my reading of sysv_shm.c: shmmap_s = malloc(size, M_SHM, M_WAITOK); seems to limit the size to what's allocable in the KVA. I only make the distinction because files can be mmap'ed in sections to exceed the offset limits for vm_object_t. I guess if we are still examining Linux vs. FreeBSD programming, then I should probably point out that SysV SHM is faster than non-anonymous mmap'ed memory, because writes don't have to be written through to the backing object. This kind of implies that it would be nice to have an extension to the PROCFS code to allow file-based access to backing objects for mapped regions. That would let you mmap MAP_ANON in one process, and access the segment from another (non-descendent) process, and dispense with the backing object that would otherwise be necessary for mmap based rendesvous. As it is right now, there is incentive to use SysV SHM in new programs on BSD to avoid the backing object write-back hit that comes with the use of the "more BSDish" mmap (e.g. this is why Oracle on FreeBSD uses SysV SHM instead of mmap). Hey, this is turning into a very interesting thread! We should ask ourselves more FreeBSD vs. XXX programming questions. 8-). 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?199902101724.KAA13526>