From: "Stephen C. Tweedie" <sct@redhat.com>
To: Mark_H_Johnson.RTS@raytheon.com
Cc: "Eric W. Biederman" <ebiederman@uswest.net>,
linux-mm@kvack.org, riel@nl.linux.org, sct@redhat.com
Subject: Re: pressuring dirty pages (2.3.99-pre6)
Date: Tue, 25 Apr 2000 17:30:12 +0100 [thread overview]
Message-ID: <20000425173012.B1406@redhat.com> (raw)
In-Reply-To: <852568CC.004F0BB1.00@raylex-gh01.eo.ray.com>; from Mark_H_Johnson.RTS@raytheon.com on Tue, Apr 25, 2000 at 09:27:57AM -0500
Hi,
On Tue, Apr 25, 2000 at 09:27:57AM -0500, Mark_H_Johnson.RTS@raytheon.com wrote:
> It would be great to have a dynamic max limit. However I can see a lot of
> complexity in doing so. May I make a few suggestions.
> - take a few moments to model the system operation under load. If the model
> says RSS limits would help, by all means lets do it. If not, fix what we have.
> If RSS limits are what we need, then
> - implement the RSS limit using the current mechanism [e.g., ulimit]
> - use a simple page removal algorithm to start with [e.g.,"oldest page first"
> or "address space order"]. The only caution I might add on this is to check that
> the page you are removing isn't the one w/ the instruction you are executing
We already have simple page removal algorithms.
The reason for the dynamic RSS limit isn't to improve the throughput
under load. It is to protect innocent processes from the effects of a
large memory hog in the system. It's easy enough to see that any pageout
algorithm which treats all pages fairly will have trouble if you have a
memory hog paging rapidly through all of its pages --- the hog process's
pages will be treated the same as any other process's pages, which means
that since the hog process is thrashing, it forces other tasks to do
likewise.
Note that RSS upper bounds are not the only way to achieve this. In a
thrashing situation, giving processes a lower limit --- an RSS guarantee
--- will also help, by allowing processes which don't need that much
memory to continue to work without any paging pressure at all.
--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/
next prev parent reply other threads:[~2000-04-25 16:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-25 14:27 Mark_H_Johnson.RTS
2000-04-25 16:30 ` Stephen C. Tweedie [this message]
2000-04-25 19:14 ` Eric W. Biederman
2000-04-25 19:47 ` Rik van Riel
2000-04-26 11:43 ` Stephen C. Tweedie
2000-04-26 11:06 ` Stephen C. Tweedie
-- strict thread matches above, loose matches on Subject: below --
2000-04-24 19:54 Rik van Riel
2000-04-24 21:27 ` Stephen C. Tweedie
2000-04-24 22:42 ` Rik van Riel
2000-04-25 9:35 ` Stephen C. Tweedie
2000-04-25 15:25 ` Rik van Riel
2000-04-25 13:58 ` Eric W. Biederman
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=20000425173012.B1406@redhat.com \
--to=sct@redhat.com \
--cc=Mark_H_Johnson.RTS@raytheon.com \
--cc=ebiederman@uswest.net \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.org \
/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