>> The worst case is perhaps when you're out of RAM servicing a page
>> fault.  There simply is no way to tell a process "I'm sorry, you get
>> ENOMEM instead of that page your PC is pointing into".
> Fair enough, but what to do if you have a mission critical service?

You call mlockall(), or if you can, mlock(), to lock all relevant pages
into core.  Or else you impose resource limits low enough compared to
the amount of swap you provide that you _can't_ run out.

...or else you risk, yes, as you say, getting a critical process nuked
at an unpredictable time.

Of course, you can also think of it as being just a case of "if you
reach that point you're under such a severe overload that we don't much
care what happens".  In some cases, this may even be a reasonable point
of view to take.

> You end up with a killed process and perhaps lost data only because
> your kernel could not say anything about memory starvation rather
> killing the first found process happened to be the largest one.

Right.  But what else is there to do?  I can see only about four
reasonable things to do when you're out of RAM when servicing a page
fault:

1) Deliver a signal to the process.

2) Kill the process.

3) Stall: make the process wait a little and hope the situation eases.

4) "When in danger or in doubt / Run in circles, scream and shout":
   stall the faulting process and kick someone else, probably a
   task-manager of some kind (presumably small and locked in core).

For (1) to be useful, the process must have arranged to handle the
signal without incurring further page faults, which is possible but
nontrivial (and even more difficult to do without just locking
everything in core, in which case you won't get the page faults
anyway).  Most processes don't have much they can do to ease a serious
RAM crunch to start with; to do it right you really want a malloc-alike
that lets you specify different areas to allocate out of for different
objects, so noncritical objects and critical objects can live in
different pages.

(2) is what's currently done.  Easy, and approximately guaranteed to
relieve the resource crunch, but with little else to recommend it
(especially since the faulting process quite likely is not the
misbehaving one, if misbehaviour is involved).

(3) sounds plausible, but has hair-rasing deadlock potential.

(4) is not suitable for general-purpose machines, though for embedded
systems (where everything running is "a part of the system"), it may be
workable.  Unless the special process is init, it introduces another
special-case process, which is somewhat gross.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B