We don't apply the datasize limits very seriously to mmap(2) calls,
but we do check that any one call doesn't bust the limit. Effectively,
cmucl was intentionally activating a bug in mmap(2) instead of clearing
the soft setrlimit(2).

Sometimes I think those limits are more trouble than they are worth,
although mmap(2) would have returned a reasonable ENOMEM in the
limit-busting case. Or, you could argue that the goofy check in
mmap(2) is worse than no check at all, because it's confusing.

	r.o.s.s

> From: Thor Lancelot Simon <tls@rek.tjls.com>
>
> On Sun, Feb 17, 2002 at 04:30:00PM -0600, John R Towler wrote:
> > 
> > Difficulties apparently are manifest in the OS facilities desired in
> > the new, experimental port of cmucl to NetBSD/x86.  Wrt  the comments
> > below, the facilities desired are 
> > 
> > ((a) the ability to map memory in chunks >= 128M 
>
> I don't understand what the problem is, here.  I mmap more than 128MB
> at a time with some regularity; no problems to report.
>
> Perhaps the author of the comment you enclosed didn't check that his
> resource limits were set appropriately?  I note that:
>
> 1) The default "datasize" limit is 128MB
>
> 2) Many other Unix variants incorrecly *don't count mmap allocations
>    against *any* resource limit *at all**, allowing the use of mmap()
>    to completely bollix up the system.