From: Chris Mason <chris.mason@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] Improve buffered streaming write ordering
Date: Thu, 02 Oct 2008 12:12:35 -0400 [thread overview]
Message-ID: <1222963955.12099.12.camel@think.oraclecorp.com> (raw)
In-Reply-To: <1222950054.6745.18.camel@think.oraclecorp.com>
On Thu, 2008-10-02 at 08:20 -0400, Chris Mason wrote:
> On Wed, 2008-10-01 at 21:52 -0700, Andrew Morton wrote:
> > On Wed, 01 Oct 2008 14:40:51 -0400 Chris Mason <chris.mason@oracle.com> wrote:
> >
> > > The patch below changes write_cache_pages to only use writeback_index
> > > when current_is_pdflush(). The basic idea is that pdflush is the only
> > > one who has concurrency control against the bdi, so it is the only one
> > > who can safely use and update writeback_index.
> >
> > Another approach would be to only update mapping->writeback_index if
> > nobody else altered it meanwhile.
> >
>
> Ok, I can give that a short.
>
I tried a few variations on letting anyone update writeback_index if it
hadn't changed, including always letting pdflush update it, and only
letting non-pdflush update it when walking forward in the file.
They all performed badly for both xfs and ext4, making me think the real
benefit from my patch comes with making non-pdflush writers start at 0.
So I'm a bit conflicted on this one. The filesystems could be doing
better, but the current logic in write_cache_pages isn't very
predictable.
-chris
next prev parent reply other threads:[~2008-10-02 16:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 18:40 [PATCH] Improve buffered streaming write ordering Chris Mason
2008-10-02 4:52 ` Andrew Morton
2008-10-02 12:20 ` Chris Mason
2008-10-02 16:12 ` Chris Mason [this message]
2008-10-02 18:18 ` Aneesh Kumar K.V
2008-10-02 19:44 ` Andrew Morton
2008-10-02 23:43 ` Dave Chinner
2008-10-03 19:45 ` Chris Mason
2008-10-06 10:16 ` Aneesh Kumar K.V
2008-10-06 14:21 ` Chris Mason
2008-10-07 8:45 ` Aneesh Kumar K.V
2008-10-07 9:05 ` Christoph Hellwig
2008-10-07 10:02 ` Aneesh Kumar K.V
2008-10-07 13:29 ` Theodore Tso
2008-10-07 13:36 ` Christoph Hellwig
2008-10-07 14:46 ` Nick Piggin
2008-10-07 13:55 ` Peter Staubach
2008-10-07 14:38 ` Chuck Lever
2008-10-09 15:11 ` Chris Mason
2008-10-10 5:13 ` Dave Chinner
2008-10-03 1:11 ` Chris Mason
2008-10-03 2:43 ` Nick Piggin
2008-10-03 12:07 ` Chris Mason
2008-10-02 18:08 ` Aneesh Kumar K.V
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=1222963955.12099.12.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).