On Tue, 20 Jul 1999 15:15:09 +0200 (MEST), Bernd Paysan
<bernd.paysan@gmx.de> said:
> 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.
Nearly. This might be nice, except for one particular problem: it means
that processes can run up a huge set of dirty pages before hitting any
limit at all. These pages _are_ a cost even if the rest of the OS wants
pages back pronto: we have to write them back to disk before we can get
the memory back.
If we honour the RSS limit and write the pages back before leaving them
cached, then the "surplus" pages above RSS are always clean and can
always be reclaimed rapidly by the OS should we need them for anything
else.
It's a tradeoff, of course: neither option is a clear win over the other.
> 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,
Actually, with RSS limits this doesn't happen. The max RSS _does_ cure
this --- the large processes which hog memory simply cannot put that
much VM pressure on normal tasks, because they are being penalised
automatically via the RSS ceiling.
But yes, adaptive RSS guarantees are another thing I'd like to see
eventually.
> 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.
Without an aging mechanism of some sort, you simply do not know which
pages are frequently used. Think of the "age" as rather being "count of
how much it has been accessed recently" --- that's what it is. So you
don't like aging, but want to identify frequently accessed pages... just
how exactly do you propose to do it?
> 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).
It also stops the sysadmin from being able to login once an existing
process has started to hog memory. Ouch.
> 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.
You cannot achieve that if you are proposing to penalise newly-allocated
pages. RSS quotas/limits seem an ideal way of attacking this problem:
they allow us to distinguish between tasks in a useful manner, rather
than treating all pages the same.
--Stephen
-
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/