Re: time tells all about kernel VM's

[Helge Hafting]

safemode wrote:
[...]
> B.  The VM has this need to redistribute cache and buffer so that an OOM
> situation doesn't take place until all the ram is basically being used.  The
> problem is that currently the VM will swap out stuff it isn't using and
> without buffer it must read from the drive (which is being used to swap)
> which takes more cpu which isn't there because the app is locking the kernel
> up trying to allocate memory (see why dbench causes mp3 skips).  So what
> happens is that the kernel cant swap because the hdd io is being strangled by
> the process that's going out of control (kghostview) which means that the VM
> is stuck doing this redistribution at a snails pace and the OOM situation
> never occurs (or occurs many days later when you've died of starvation).
> Leaving you deadlocked on a kernel with a VM that is supposed to conquer this
> situation and make it a thing of the past.
> 
Any VM with paging _can_ be forced into a trashing situation where
a keypress takes hours to process.  A better VM will take more pressure
before it gets there and performance will degrade more gradually.
But any VM can get into this situation.

Consider a malicious app that uses lots of RAM but deliberately leaves
a _single_ page free.  OOM will never happen, but the machine is
brought to its knees anyway.  (You can also get in trouble by running
a few hundred infinite loops, with some dummy io so they too get the
io boost other processes gets.)

Swapping out whole processes can help this, but it will merely
move the point where you get stuck.  A load control system that
kills processes when response is too slow is possible, but
the problem here is that you can't get people to agree
on how bad is too bad.  It is sometimes ok to leave the machine 
alone crunching a big problem over the weekend.  And sometimes
you _need_ response much faster.

And what app to kill in such a situation?
You had a single memory pig, but it aint necessarily so.

Helge Hafting