All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: riel@redhat.com, andrea@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][5/?] count writeback pages in nr_scanned
Date: Wed, 5 Jan 2005 13:44:57 -0800	[thread overview]
Message-ID: <20050105134457.03aca488.akpm@osdl.org> (raw)
In-Reply-To: <20050105174934.GC15739@logos.cnet>

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
> On Wed, Jan 05, 2005 at 01:50:51PM -0500, Rik van Riel wrote:
> > On Wed, 5 Jan 2005, Andrea Arcangeli wrote:
> > 
> > >Another unrelated problem I have in this same area and that can explain
> > >VM troubles at least theoretically, is that blk_congestion_wait is
> > >broken by design. First we cannot wait on random I/O not related to
> > >write back. Second blk_congestion_wait gets trivially fooled by
> > >direct-io for example. Plus the timeout may cause it to return too early
> > >with slow blkdev.

That's true, as we discussed a couple of months back.  But the current code
is nice and simple and has been there for a couple of years with no
observed problems.


> > Or the IO that just finished, finished for pages in
> > another memory zone, or pages we won't scan again in
> > our current go-around through the VM...
> 
> Thing is there is no distinction between pages which have been written out 
> for what purpose at the block level. 
> 
> One can conjecture the following: per-zone waitqueue to be awakened from 
> end_page_writeback() (for PG_reclaim pages only of course), and a function
> to wait on the perzone waitqueue:
> 
>  wait_vm_writeback (zone, timeout);
> 
> Instead of the current blk_congestion_wait() on try_to_free_pages/balance_pgdat.
> 

The caller would need to wait on all the zones which can satisfy the
caller's allocation request.  A bit messy, although not rocket science. 
One would have to be careful to avoid additional CPU consumption due to
delivery of multiple wakeups at each I/O completion.

We should be able to demonstrate that such a change really fixes some
problem though.  Otherwise, why bother?



  reply	other threads:[~2005-01-05 21:46 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03 17:25 [PATCH][5/?] count writeback pages in nr_scanned Rik van Riel
2005-01-05 10:08 ` Andrew Morton
2005-01-05 18:06   ` Andrea Arcangeli
2005-01-05 18:50     ` Rik van Riel
2005-01-05 17:49       ` Marcelo Tosatti
2005-01-05 21:44         ` Andrew Morton [this message]
2005-01-05 20:32           ` Marcelo Tosatti
2005-01-05 23:51             ` Nick Piggin
2005-01-06  1:27               ` Rik van Riel
2005-01-06  1:33                 ` Nick Piggin
2005-01-06  1:37                   ` Andrew Morton
2005-01-06  1:40                     ` Nick Piggin
2005-01-06  1:52                       ` Andrea Arcangeli
2005-01-06  1:36                 ` Andrew Morton
2005-01-06  3:42                   ` Rik van Riel
2005-01-06  3:50                     ` Nick Piggin
2005-01-06  4:26                       ` Andrew Morton
2005-01-06  4:35                         ` Nick Piggin
2005-01-06  4:47                           ` Andrew Morton
2005-01-06  4:55                             ` Nick Piggin
2005-01-06  5:03                               ` Andrea Arcangeli
2005-01-06  8:06                               ` Jens Axboe
2005-01-06  8:16                                 ` memory barrier in ll_rw_blk.c (was Re: [PATCH][5/?] count writeback pages in nr_scanned) Nick Piggin
2005-01-06  8:32                                   ` Jens Axboe
2005-01-06  8:53                                     ` Nick Piggin
2005-01-06 12:00                                       ` Jens Axboe
2005-01-06  4:59                             ` [PATCH][5/?] count writeback pages in nr_scanned Andrea Arcangeli
2005-01-06  5:05                               ` Andrew Morton
2005-01-06  5:17                                 ` Andrea Arcangeli
2005-01-06  5:19                                   ` Nick Piggin
2005-01-06  5:25                                     ` Andrea Arcangeli
2005-01-06  5:36                                       ` Nick Piggin
2005-01-06  5:44                                         ` Nick Piggin
2005-01-06  5:37                                       ` Andrew Morton
2005-01-06  5:59                                         ` Andrea Arcangeli
2005-01-06 13:28                                         ` Rik van Riel
2005-01-06  5:32                                     ` Andrew Morton
2005-01-06  5:46                                       ` Andrea Arcangeli
2005-01-06  5:59                                         ` Andrew Morton
2005-01-06  6:16                                           ` Andrea Arcangeli
2005-01-06  5:06                               ` Nick Piggin
2005-01-06  5:21                                 ` Andrea Arcangeli
2005-01-05 23:26 ` 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=20050105134457.03aca488.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=riel@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 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.