I think one can have that with even less overhead: don't start reclaiming
until physical memory runs low. And when it does, reclaim from processes
which exceed their RSS limit most.
But however, instead of having a guaranteed maximum RSS, it would be much
better to have a sort of guaranteed minimum RSS. The current situation under
Linux with too many too large processes (i.e. fork-bombing memory hog) is
that well-behaving processes get swapped out totally, and virtually have no
change to get in again - they may claim one page, this page is swapped in,
and swapped out again, before the process can really use it (it's waiting for
the second page it needs, and during that time, the first page ages and gets
swapped out).
IMHO I just don't like Linux' aging policy. Aging should not have anything
to do with load (don't age faster under load), aging just should give a
score of which pages have least worth, and therefore get swapped out first.
Well-established, frequently used pages certainly are worth to keep in memory.
Paging in is more expensive than paging out, so a recently paged in page
should not be paged out again fast. Newly allocated pages should not have a
high score, they have to be used before they gain score (this keeps processes
from growing quickly at the cost of others). Processes that are stuck due to
a page fault should have their page ages frozen, because they have no change
to access them now. And don't take the last shirt of a process (ok, you can
swap out that spare httpd that didn't run for three days).
The current aging really prefers malicious memory hogs over ordinary
processes - currently you have about 2 or 3 seconds with 64 Mb RAM before a
fork-bombing memory hog has paged out everything else. My goal is to be able to
log into a machine under attack, start top (even if it takes a little
longer), and killall -9 the offending processes. Without loosing any other
processes (done by Rik's chooser).
-- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/Sent through Global Message Exchange - http://www.gmx.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/