From: Rik van Riel <riel@conectiva.com.br>
To: "Eric W. Biederman" <ebiederman@uswest.net>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Mark_H_Johnson.RTS@raytheon.com, linux-mm@kvack.org
Subject: Re: pressuring dirty pages (2.3.99-pre6)
Date: Tue, 25 Apr 2000 16:47:52 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0004251642500.10408-100000@duckman.conectiva> (raw)
In-Reply-To: <m1snwadmcp.fsf@flinx.biederman.org>
On 25 Apr 2000, Eric W. Biederman wrote:
> "Stephen C. Tweedie" <sct@redhat.com> writes:
> > 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.
>
> Agreed all I suggest for now was implement a max limit.
> The dynamic was just food for thought.
I have a solution for this.
My current anti-hog code already looks at what the biggest
process is. Any process which is in the same size class will
get a special bit set and has to call swap_out() on allocation
of a new page.
This will:
1) slow down the hogs a little, but give most slowdown to the
hog that does most allocations
2) will cause memory in processes to be unmapped, populating
the lru queue without the help of kswapd ...
3) ... this makes sure we have a whole bunch of easily freeable
memory around ...
4) ... which in turn makes it easy to keep up with the high IO
rates which some memory hogs require, because it's easier to
free memory
So in __alloc_pages():
if (current->hog)
swap_out();
Of course this won't penalise processes like bonnie, which just
do a lot of IO, but that *isn't needed* at all because the cache
memory used for these processes is not mapped and occupies a big
portion of the lru queue .. so it's quite likely that we'll free
memory from this process when we free something.
In fact, the MM code I'm playing with at the moment seems pretty
resistant against things like bonnie and tar ...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
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 19:47 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
2000-04-25 19:14 ` Eric W. Biederman
2000-04-25 19:47 ` Rik van Riel [this message]
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=Pine.LNX.4.21.0004251642500.10408-100000@duckman.conectiva \
--to=riel@conectiva.com.br \
--cc=Mark_H_Johnson.RTS@raytheon.com \
--cc=ebiederman@uswest.net \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.org \
--cc=sct@redhat.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