> > 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".
> 
> I think that flag is already permanently set, since I don't think
> processes are ever killed for VM shortages.
> 
> The resource that is in short supply in the circumstance in question is
> *physical* pages: the kill happens when a process takes a page fault on
> a perfectly good virtual page that doesn't have a physical page at the
> moment, and the fault handler gets failure when trying to allocate a
> physical page for it.
> 
> This does imply a VM crunch, because this can't happen until swap is
> full - otherwise something is paged out to make room.  (Well, or unless
> too much stuff is locked in core; there are limits to prevent that from
> happening, but they presumably could in principle be set
> inappropriately.)

A subtlety that I'd missed, but in this case there is no need to kill the 
process -- simply swap it out, since we know that all its vm resources are 
backed by swap.  When the 'problem' goes away it can be resumed.  Just 
freeing up the pages from the process may be sufficient to resolve the 
deadlock elsewhere, and if it isn't, well another process that hadn't 
pre-announced it's memory usage takes the hit.

Note, I assume that it is safe to completely suspend the process; since if 
it weren't it should have mlocked itself into memory in the first place.

I'm not suggesting that every process should start playing this game 
(perhaps there needs to be some restriction on who can ask for this); but 
the idea should be that system-critical daemons could do this to ensure 
that they weren't vicimized in a way that would bring the system down.

> 
> > 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.
> 
> And if that `request' takes the form of a page fault?  There is no
> overt way to refuse a page fault; that's where we came in.

The requests I had in mind were things like mmap, sbrk etc which are 
requesing that the process expand its page set.

R.