From owner-freebsd-hackers  Tue Dec 10 23:37:01 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id XAA24320
          for hackers-outgoing; Tue, 10 Dec 1996 23:37:01 -0800 (PST)
Received: from pdx1.world.net (pdx1.world.net [192.243.32.18])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA24314
          for <hackers@freebsd.org>; Tue, 10 Dec 1996 23:36:59 -0800 (PST)
From: proff@suburbia.net
Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id XAA06839 for <hackers@freebsd.org>; Tue, 10 Dec 1996 23:37:19 -0800 (PST)
Received: (qmail 8100 invoked by uid 110); 11 Dec 1996 07:36:26 -0000
Message-ID: <19961211073626.8099.qmail@suburbia.net>
Subject: Re: Multiple Buffer allocation of Shared Memory
In-Reply-To: <Pine.NEB.3.95.961210151724.374T-100000@hub.org> from "Marc G. Fournier" at "Dec 10, 96 03:29:54 pm"
To: scrappy@hub.org (Marc G. Fournier)
Date: Wed, 11 Dec 1996 18:36:26 +1100 (EST)
Cc: hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 	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.