All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: nonblocking-vm.patch
Date: Wed, 04 Sep 2002 13:14:17 -0700	[thread overview]
Message-ID: <3D766999.A9C14E1E@zip.com.au> (raw)
In-Reply-To: Pine.LNX.4.44L.0209041640171.1857-100000@imladris.surriel.com

Rik van Riel wrote:
> 
> On Wed, 4 Sep 2002, Andrew Morton wrote:
> 
> > We do need something in there to prevent kswapd from going berzerk.
> 
> Agreed, but it can be a lot simpler than your idea.
> 
> As long as we can free up to zone->pages_high pages,
> we don't need to throttle since we're succeeding in
> keeping enough pages free to not be woken up for a
> while.

OK, so after we've taken a scan through shrink_caches,
if we didn't reclaim the required pages then take a
nap.

Suspect that would work.  I get a bit upset over scanning non-reclaimable
pages (they shouldn't have been on that list!) But instrumentation
indicates that perhaps I'm being silly ;)

> If we don't succeed in freeing enough pages, that is
> because the pages are still under IO and haven't hit
> the disk yet.  In this case, we need to wait for the
> IO to finish, or at least for some of the pages to
> get cleaned.  We can do this by simply refusing to
> scan that zone again for a number of jiffies, say
> 1/4 of a second.

Well, it may be better to terminate that sleep earlier if IO
completes.  We can do that in end_page_writeback or in
blk_congestion_wait().   The latter takes a timeout, and
wakes you up earlier if _any_ queue exits congestion, or
if any queue puts back a request against an uncongested queue.

Which is, I think, precisely what we want - a request typically
covers a whole bunch of pages.  If the dirty memory is backed
by an non-request-oriented device (are there any such?  NFS seems
to be synchronous a lot of the time) then you'll hit the timeout.
--
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-mm.org/

  reply	other threads:[~2002-09-04 20:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-04 10:28 nonblocking-vm.patch Andrew Morton
2002-09-04 13:32 ` nonblocking-vm.patch Rik van Riel
2002-09-04 18:44   ` nonblocking-vm.patch Andrew Morton
2002-09-04 19:42     ` nonblocking-vm.patch Rik van Riel
2002-09-04 20:14       ` Andrew Morton [this message]
2002-09-04 20:55         ` nonblocking-vm.patch Rik van Riel
2002-09-04 21:22           ` nonblocking-vm.patch Andrew Morton
2002-09-04 21:34             ` nonblocking-vm.patch Rik van Riel
2002-09-04 21:46               ` nonblocking-vm.patch Andrew Morton
2002-09-04 22:12                 ` nonblocking-vm.patch Rik van Riel
2002-09-04 22:41                   ` nonblocking-vm.patch Andrew Morton
2002-09-04 22:46                     ` nonblocking-vm.patch Rik van Riel
2002-09-05  5:43                       ` nonblocking-vm.patch Andrew Morton

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=3D766999.A9C14E1E@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.