> >> You call mlockall(), or if you can, mlock(), to lock all relevant
> >> pages into core.  Or [...]
> > `mlock' only provides you with a way to find out if there is still
> > any physical memory available for allocation in the system.
> 
> That's not how the manpage describes it.  The manpage says that it
> locks virtual pages into core, that is, it arranges that accesses to
> them will never incur page faults.  This does imply finding physical
> pages to back them, yes, but it does a lot more than that.

It might be useful to have a call (or a flag to mlock) that says "make 
sure that I have vm resources sufficiently allocated to ensure that I 
won't be killed due to vm shortages, on the condition that I don't request 
any further pages of memory".

That is, for each page of my stack (up to some limit that I've told you 
about) you allocate some backing store, and for each page that is 
copy-on-write you either copy it now, or provide the backing store now to 
ensure it can be copied.
Obviously any request for further resources will have to be treated with 
the same way as we treat other requests for resources: it might be refused.

> 
> I wonder if there would be any use for something like an MCL_LAZY flag
> to mlockall, which basically says "don't lock anything now, but start
> remembering what pages are touched" and then MCL_LOCKLAZY which says
> "now, convert everything touched since the last MCL_LAZY to real locked
> pages", so as to permit locking data structures by setting LAZY,
> accessing them, and then calling LOCKLAZY to do the locking -
> regardless of whether they're all on one page or scattered throughout
> dozens.

Hmm, I suggested something similar to this about six months ago as a way 
of taming the memory grabbing antics of ntpd; but since then some of the 
more rediculous locking of unnecessary stack space has been eliminated and 
the problem is less of an issue now in that area -- I still think the idea 
has merit though.

R.