From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrey Savochkin <saw@saw.sw.com.sg>
Cc: John Fremlin <vii@penguinpowered.com>,
linux-mm@kvack.org, Stephen Tweedie <sct@redhat.com>
Subject: Re: RSS guarantees and limits
Date: Tue, 27 Jun 2000 04:26:42 +0100 [thread overview]
Message-ID: <20000627042642.D1065@redhat.com> (raw)
In-Reply-To: <20000624192245.A6617@saw.sw.com.sg>; from saw@saw.sw.com.sg on Sat, Jun 24, 2000 at 07:22:45PM +0800
Hi,
On Sat, Jun 24, 2000 at 07:22:45PM +0800, Andrey Savochkin wrote:
>
> Small applications are not always good, as well as big are not bad.
> We just want good memory service for those applications which we want to have
> it :-) It hears like tautology, but that it. It's completely administrator
> policy decision.
Somewhat, but not entirely.
Remember that we were talking about both RSS limits and RSS guarantees
being dymamic. RSS guarantees for small processes (based on their
fault activity, of course, so that idle small tasks can still be
swapped out) are perhaps dependent on what those tasks are actually
doing if the object is to have them compete against each other more
fairly.
However, RSS limits on the largest tasks in the system have an
entirely different effect --- they prevent swap storms from
overwhelming small tasks entirely, by placing more of the burden of
the swapping on the large task.
If a task is so large that it is thrashing, then removing a few 100K
from its RSS doesn't usually have all that a dramatic effect on its
performance. Remember, we'll only be doing this pruning if there is
continuing memory pressure. If that large task becomes the only task
wanting more memory again, we can let its RSS limit creep up again.
That way, processes which just fit into memory on an idle system will
continue to work just fine, but once we get memory contention, they
won't stop the rest of the system from getting going again.
Cheers,
Stephen
--
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/
prev parent reply other threads:[~2000-06-27 3:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-21 22:29 [RFC] " Rik van Riel
2000-06-22 18:00 ` John Fremlin
2000-06-22 19:12 ` Rik van Riel
2000-06-22 21:19 ` Stephen Tweedie
2000-06-22 21:37 ` Rik van Riel
2000-06-22 22:48 ` John Fremlin
2000-06-22 23:59 ` Stephen Tweedie
2000-06-23 16:08 ` John Fremlin
2000-06-22 22:39 ` John Fremlin
2000-06-22 23:27 ` Rik van Riel
2000-06-23 0:49 ` Ed Tomlinson
2000-06-23 13:45 ` Rik van Riel
2000-06-23 15:36 ` volodya
2000-06-23 15:52 ` John Fremlin
2000-06-24 11:22 ` Andrey Savochkin
2000-06-27 3:26 ` Stephen C. Tweedie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000627042642.D1065@redhat.com \
--to=sct@redhat.com \
--cc=linux-mm@kvack.org \
--cc=saw@saw.sw.com.sg \
--cc=vii@penguinpowered.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox