All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	chris.mason@oracle.com, tytso@mit.edu, akpm@linux-foundation.org,
	trond.myklebust@fys.uio.no
Subject: Re: [PATCH 6/7] writeback: separate starting of sync vs opportunistic writeback
Date: Tue, 15 Sep 2009 15:17:08 +0200	[thread overview]
Message-ID: <20090915131707.GM23126@kernel.dk> (raw)
In-Reply-To: <20090915130829.GA7507@infradead.org>

On Tue, Sep 15 2009, Christoph Hellwig wrote:
> On Tue, Sep 15, 2009 at 03:04:19PM +0200, Jens Axboe wrote:
> > 
> > >   Let's have a look at the flags in wbc:
> > >   nonblocking - Currently only set by direct callers of ->writepage() BUT
> > >                 originally wb_kupdate() and background_writeout() also
> > >                 set this flag. Since filesystems and write_cache_pages()
> > > 		use the flag we should set it for equivalent writeouts as
> > >                 well. This should be fixed...
> > 
> > Since this is all handled by the dedicated thread now, dropping the
> > nonblocking bit was on purpose. What would the point be, except for
> > stopping pdflush being blocked on request allocation?
> 
> Note that this flag just caused utter mess traditionally.  btrfs decided
> to ignore it completely and ext4 partially.  Removing this check in
> XFS increases large bufferd write loads massively.
> 
> Just half-removing it is a bad idea, though - if you don't set it
> anymore please kill it entirely.

I haven't touched it, except removing it from the caller where it
doesn't make sense anymore. If you think we should kill it completely,
then lets look at that in a few days. I've got more than enough stuff
queued up for inclusion now that I need to test and verify before doing
even more cleanups/changes :-)

-- 
Jens Axboe


  reply	other threads:[~2009-09-15 13:17 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14  9:36 [PATCH 0/7] Post merge per-bdi writeback patches v2 Jens Axboe
2009-09-14  9:36 ` [PATCH 1/7] writeback: merely wakeup flusher thread if work allocation fails for WB_SYNC_NONE Jens Axboe
2009-09-14 12:34   ` Jan Kara
2009-09-14 12:39     ` Jens Axboe
2009-09-14 13:19       ` Christoph Hellwig
2009-09-14  9:36 ` [PATCH 2/7] Assign bdi in super_block Jens Axboe
2009-09-14 13:02   ` Jan Kara
2009-09-14 18:25     ` Trond Myklebust
2009-09-14 18:36       ` Jens Axboe
2009-09-15 10:14         ` Jan Kara
2009-09-15 10:22           ` Jens Axboe
2009-09-15 13:16           ` Trond Myklebust
2009-09-14  9:36 ` [PATCH 3/7] writeback: only use bdi_writeback_all() for WB_SYNC_NONE writeout Jens Axboe
2009-09-14 13:12   ` Jan Kara
2009-09-14  9:36 ` [PATCH 4/7] writeback: use RCU to protect bdi_list Jens Axboe
2009-09-14 11:10   ` Minchan Kim
2009-09-14 11:11     ` Jens Axboe
2009-09-14  9:36 ` [PATCH 5/7] writeback: inline allocation failure handling in bdi_alloc_queue_work() Jens Axboe
2009-09-14 13:13   ` Jan Kara
2009-09-14  9:36 ` [PATCH 6/7] writeback: separate starting of sync vs opportunistic writeback Jens Axboe
2009-09-14 13:33   ` Jan Kara
2009-09-14 13:42     ` Christoph Hellwig
2009-09-14 19:28       ` Jens Axboe
2009-09-14 19:42         ` Jens Axboe
2009-09-15  9:08           ` Jan Kara
2009-09-15  9:14             ` Jens Axboe
2009-09-15 11:44               ` Jens Axboe
2009-09-15 12:58                 ` Jan Kara
2009-09-15 13:04                   ` Jens Axboe
2009-09-15 13:08                     ` Christoph Hellwig
2009-09-15 13:17                       ` Jens Axboe [this message]
2009-09-15 14:01                       ` Jan Kara
2009-09-15 14:09                         ` Chris Mason
2009-09-14  9:36 ` [PATCH 7/7] writeback: splice dirty inode entries to default bdi on bdi_destroy() Jens Axboe
2009-09-14 10:56   ` Jens Axboe

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=20090915131707.GM23126@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    --cc=tytso@mit.edu \
    /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.