Date: Wed, 11 Dec 1996 18:36:26 +1100 (EST) From: proff@suburbia.net To: scrappy@hub.org (Marc G. Fournier) Cc: hackers@freebsd.org Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <19961211073626.8099.qmail@suburbia.net> In-Reply-To: <Pine.NEB.3.95.961210151724.374T-100000@hub.org> from "Marc G. Fournier" at "Dec 10, 96 03:29:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Now, "child" processes accessing that MMAP'd area...Terry (I believe?) > mentioned passing the file descriptor through a socket from the parent to > the child, which, to me, sounds okay if you have few children reading the > mmap()'d region...but what I'm working on is going to require 1000's of > child processes reading that mmap()'d region, and having 1 socket open for > each child doesn't sound very efficient. Consider using rfork() (freebsd) and clone() (linux). If you want something more portable, or you (or your libraries) use static variables (and you can't easily change their mappings). Then I advise you to examine the solution I implemented in nntpcache: 1. parent maps file/anonymous region with MAP_SHARED 2. children fork off and automatically have this shared region in their memory space There are a few caveats. 1. growth of the mmaped region can only be made by the parent and is only reflected in newly born children. You can circumvent this by simply mapping very large regions initially (there is almost no overhead for unused pages, although many unix's will stupidly insist that map_size<phsical_mem for MAP_ANONYMOUS regions, despite the fact virtual mem is used) 2. Quite a few unix's have bugs/limitations in their mmap()ing code. This means that sometimes you can't use MAP_ANONYMOUS regions, and have to map /dev/zero or a real file instead. I've tried to automagically accommodate for this with my mmap_test suite and take action accordingly. 3. Actually splitting up the memory in the mmaped region can be trying. I've modified mmalloc (from cygnus/gdb) to work with the above system (and to support 64 bit void pointers). However, I'd dearly love to see region limited mallocs natively in FreeBSD using phkmalloc (this is an official request ;). This would be a great boon. -Julian A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19961211073626.8099.qmail>