linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@conectiva.com.br>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-mm@kvack.org
Subject: Re: pressuring dirty pages (2.3.99-pre6)
Date: Mon, 24 Apr 2000 19:42:12 -0300 (BRST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0004241922270.5572-100000@duckman.conectiva> (raw)
In-Reply-To: <20000424222702.C3389@redhat.com>

On Mon, 24 Apr 2000, Stephen C. Tweedie wrote:
> On Mon, Apr 24, 2000 at 04:54:38PM -0300, Rik van Riel wrote:
> > 
> > I've been trying to fix the VM balance for a week or so now,
> > and things are mostly fixed except for one situation.
> > 
> > If there is a *heavy* write going on and the data is in the
> > page cache only .. ie. no buffer heads available, then the
> > page cache will grow almost without bounds and kswapd and
> > the rest of the system will basically spin in shrink_mmap()...
> 
> shrink_mmap is the problem then -- it should be giving up sooner
> and letting try_to_swap_out() deal with the pages.  mmap()ed
> dirty pages can only be freed through swapper activity, not via
> shrink_mmap().

That will not work. The problem isn't that kswapd eats cpu,
but the problem is that the dirty pages completely dominate
physical memory.

I've tried the "giving up earlier" option in shrink_mmap(),
but that leads to memory filling up just as badly and giving
us the same kind of trouble.

I guess what we want is the kind of callback that we do in
the direction of the buffer cache, using something like the
bdflush wakeup call done in try_to_free_buffers() ...

Maybe a "special" return value from shrink_mmap() telling
do_try_to_free_pages() to run swap_out() unconditionally
after this succesful shrink_mmap() call?  Maybe even with
severity levels?

Eg. more calls to swap_out() if we encountered a lot of
dirty pages in shrink_mmap() ???

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/

  reply	other threads:[~2000-04-24 22:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-24 19:54 Rik van Riel
2000-04-24 21:27 ` Stephen C. Tweedie
2000-04-24 22:42   ` Rik van Riel [this message]
2000-04-25  9:35     ` Stephen C. Tweedie
2000-04-25 15:25       ` Rik van Riel
2000-04-25 13:58     ` Eric W. Biederman
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
2000-04-26 11:43       ` Stephen C. Tweedie
2000-04-26 11:06     ` Stephen C. Tweedie

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.0004241922270.5572-100000@duckman.conectiva \
    --to=riel@conectiva.com.br \
    --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