On Sun, 7 Jul 2002, Chuck Silvers wrote:

> since SHM segments actually do have names and they exist independently
> of mappings in any process, I'll argue that they're really more like
> files than anonymous memory.  SHM segments also have owners, permissions
> timestamps, etc.  the SHM namespace is basically a virtual-memory-backed
> file system with a flat namespace, so it would really make more sense
> to think of it like a file system.

All right, I think I'll buy that. But you suggest a RAM+swap-at-the-moment
check; I was thinking more along the lines of a limit set at system boot.
The latter seems simpler to me; one could just set the sysctl variable
at boot time to, say, 1/2 the total number of pages in RAM and swap, and
then users can see right there what the limit is.

> trying to apply a per-process limit to SHM creation doesn't make a lot of
> sense, since a program could trivially work around that by forking and
> having its children create whatever segments it wants, then just attach
> to those already-existing segments.  processes are really just mapping
> these SHM "files".

Yeah, true enough. But the same is true of memory allocation in general,
isn't it. Anybody who forks enough can eat up all your memory. But if you
don't think a per-process limit is necessary, I'll happily agree with you
and save doing some work. :-)

> if you really want to do this, I'd suggest having that flag just trigger an
> implicit mlock() after a segment is attached.  that should do exactly
> what you'd want, including enforcing limits on locked memory.

That's more or less what I was hoping could work. Thanks for the tip.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC