Re: suspend processes at load (was Re: a simple OOM ...)

[James A. Sutherland <jas88@cam.ac.uk>]

On Sat, 21 Apr 2001 20:41:40 +0100, you wrote:

>>> Note that process suspension already happens, but with too fine a
>>> granularity (the scheduler) - that's what causes the problem. If one
>>> process were able to run uninterrupted for, say, a second, it would
>>> get useful work done, then you could switch to another. The current
>>> scheduling doesn't give enough time for that under thrashing
>>> conditions.
>>
>>This suggests that a very simple approach might be to just increase
>>the scheduling granularity as the machine begins to thrash. IOW,
>>use the existing scheduler as the "suspension scheduler".
>
>That might possibly work for some loads, mostly where there are some
>processes which are already swapped-in (and have sensible working sets)
>alongside the "thrashing" processes.  That would at least give the
>well-behaved processes some chance to keep their "active" bits up to date.

The trouble is, thrashing isn't really a process level issue: yes,
there are a group of processes causing it, but you don't have
"thrashing processes" and "non-thrashing processes". Like a car with
one wheel stuck in a pool of mud without a diff-lock: yes, you have
one or two point(s) where all your engine power is going, and the
other wheels are just spinning, but as a result the whole car is going
nowhere! In both cases, the answer is to "starve" the spinning
wheel(s) of power, allowing the others to pull you out...

>However, it doesn't help at all for the cases where some paging-in has to
>be done for a well-behaved but only-just-accessed process.  

Yes it does: we've suspended the runaway process (Netscape, Acrobat
Reader, whatever), leaving enough RAM free for login to be paged in.

>Example of a
>critically important process under this category: LOGIN.  :)  IMHO, the
>only way to sensibly cater for this case (and a few others) is to update
>the page-replacement algorithm.

Updating the page replacement algorithm will help, but our core
problem remains: we don't have enough pages for the currently active
processes! Either we starve SOME processes, or we starve all of
them...


James.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/