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

[Jonathan Morton <chromi@cyberspace.org>]

>>No, it doesn't.  If we stick with the current page-replacement policy, then
>>regardless of what we do with the size of the timeslice, there is always
>>going to be the following situation:
>
>This is not just a case of increasing the timeslice: the suspension
>strategy avoids the penultimate stage of this list happening:
>
>>- Large process(es) are thrashing.
>>- Login needs paging in (is suspended while it waits).
>>- Each large process gets it's page and is resumed, but immediately page
>>faults again, gets suspended
>>- Memory reserved for Login gets paged out before Login can do any useful
>>work
>
>Except suspended processes do not get scheduled for a couple of
>seconds, meaning login CAN do useful work.

But login was suspended because of a page fault, so potentially it will
*also* get suspended for just as long as the hogs.  Unless, of course, the
suspension time is increased with page fault count per process.

>Not really. Your WS suggestion doesn't evict some processes entirely,
>which is necessary under some workloads.

Can you give an example of such a workload?

>Distributing "fairly" is sub-optimal: sequential suspension and
>resumption of each memory hog will yield far better performance. To
>the extent some workloads fail with your approach but succeed with
>mine: if a process needs more than the current working-set in RAM to
>make progress, your suggestion leaves each process spinning, taking up
>resources.

I think we're approaching the problem from opposite viewpoints.  Don't get
me wrong here - I think process suspension could be a valuable "feature"
under extreme load, but I think that the working-set idea will perform
better and more consistently under "mild overloads", which the current
system handles extremely poorly.  Probably the only way to resolve this
argument is to actually try and implement each idea, and see how they
perform.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----


--
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/