: 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).
If you fill your machine with too many jobs and if swap exceeds RAM by a large
factor that's bound to happen. As long as you can find it out, kill the jobs
and incarcerate the user it's OK.
I don't want to have that 'repaired' since I don't see how that can be
repaired. If you want some pages locked into memory you can do that I guess.
All I'm trying to achieve in this OOM discussion is that my machine
(desktop or batch) survives an 'attack' by multiple large user jobs with all
system jobs intact.
: 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).
In order for that to work the following requirement must be fulfilled:
maximum number of jobs / user * maximum survival job size
< RAM + swap
where
maximum survival job size = the maximum size of all jobs necessary
for the survival (e.g. rlogind, bash, ...)
That means that the fork bombs have to grow above the maximum survival job
size to be harmful to the machine, and so the 'survival' jobs will likely
survive since the fork bombs will get killed.
Not that I care for the malicious case a lot.
My 'malicious' jobs are often my own.
Claus
-- claus.fischer@intel.com Intel Corporation SC12-205 ... not speaking phone +1-408-765-6808 2200 Mission College Blvd. for Intel fax +1-408-765-9322 Santa Clara, CA 95052-8119
- 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/