All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Chris Mason <chris.mason@oracle.com>,
	Jens Axboe <jens.axboe@oracle.com>
Subject: Re: why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ?
Date: Fri, 20 Aug 2010 20:44:24 +0800	[thread overview]
Message-ID: <20100820124424.GA17022@localhost> (raw)
In-Reply-To: <20100820072757.6ae9741a@tlielax.poochiereds.net>

On Fri, Aug 20, 2010 at 07:27:57AM -0400, Jeff Layton wrote:
> On Fri, 20 Aug 2010 05:19:04 -0400
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Fri, Aug 20, 2010 at 07:55:53AM +0800, Wu Fengguang wrote:
> > > Since migration and pageout still set nonblocking for ->writepage, we
> > > may keep them in the near future, until VM does not start IO on itself.
> > 
> > Why does pageout() and memory migration need to be even more
> > non-blocking than the already non-blockig WB_SYNC_NONE writeout?
> > 
> 
> Just an idle thought on this...
> 
> I think a lot of the confusion here comes from the fact that we have
> sync_mode and a bunch of flags, and it's not at all clear how
> filesystems are supposed to treat the union of them. There are also
> possible unions of flags/sync_modes that never happen in practice. It's
> not always obvious though and as filesystem implementors we have to
> consider the possibility that they might occur (consider WB_SYNC_ALL +
> for_background).
> 
> Perhaps a lot of this confusion could be lifted by getting rid of the
> extra flags and adding new sync_mode's. Maybe something like:
> 
> WB_SYNC_ALL /* wait on everything to complete */
> WB_SYNC_NONE /* don't wait on anything */
> WB_SYNC_FOR_RECLAIM /* sync for reclaim */
> WB_SYNC_FOR_KUPDATED /* sync by kupdate */
> ...etc...
> 
> That does mean that all of the filesystem specific code may need to be
> touched when new modes are added and removed. I think it would be
> clearer though about what you're supposed to do in ->writepages.

No, we are moving towards the other direction :)

I just removed the definition of wbc->nonblocking and
wbc->encountered_congestion and all of the references.

Sorry for the confusion!

Thanks,
Fengguang

WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Chris Mason <chris.mason@oracle.com>,
	Jens Axboe <jens.axboe@oracle.com>
Subject: Re: why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ?
Date: Fri, 20 Aug 2010 20:44:24 +0800	[thread overview]
Message-ID: <20100820124424.GA17022@localhost> (raw)
In-Reply-To: <20100820072757.6ae9741a@tlielax.poochiereds.net>

On Fri, Aug 20, 2010 at 07:27:57AM -0400, Jeff Layton wrote:
> On Fri, 20 Aug 2010 05:19:04 -0400
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Fri, Aug 20, 2010 at 07:55:53AM +0800, Wu Fengguang wrote:
> > > Since migration and pageout still set nonblocking for ->writepage, we
> > > may keep them in the near future, until VM does not start IO on itself.
> > 
> > Why does pageout() and memory migration need to be even more
> > non-blocking than the already non-blockig WB_SYNC_NONE writeout?
> > 
> 
> Just an idle thought on this...
> 
> I think a lot of the confusion here comes from the fact that we have
> sync_mode and a bunch of flags, and it's not at all clear how
> filesystems are supposed to treat the union of them. There are also
> possible unions of flags/sync_modes that never happen in practice. It's
> not always obvious though and as filesystem implementors we have to
> consider the possibility that they might occur (consider WB_SYNC_ALL +
> for_background).
> 
> Perhaps a lot of this confusion could be lifted by getting rid of the
> extra flags and adding new sync_mode's. Maybe something like:
> 
> WB_SYNC_ALL /* wait on everything to complete */
> WB_SYNC_NONE /* don't wait on anything */
> WB_SYNC_FOR_RECLAIM /* sync for reclaim */
> WB_SYNC_FOR_KUPDATED /* sync by kupdate */
> ...etc...
> 
> That does mean that all of the filesystem specific code may need to be
> touched when new modes are added and removed. I think it would be
> clearer though about what you're supposed to do in ->writepages.

No, we are moving towards the other direction :)

I just removed the definition of wbc->nonblocking and
wbc->encountered_congestion and all of the references.

Sorry for the confusion!

Thanks,
Fengguang

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-08-20 12:44 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-19 14:15 why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ? Jeff Layton
2010-08-19 14:37 ` Christoph Hellwig
2010-08-19 14:37   ` Christoph Hellwig
2010-08-19 14:37   ` Christoph Hellwig
2010-08-19 14:58   ` Trond Myklebust
2010-08-19 14:58     ` Trond Myklebust
2010-08-19 15:11     ` Jeff Layton
2010-08-19 15:11       ` Jeff Layton
2010-08-19 15:24     ` Christoph Hellwig
2010-08-19 15:24       ` Christoph Hellwig
2010-08-19 15:24       ` Christoph Hellwig
2010-08-19 19:16     ` Jeff Layton
2010-08-19 19:16       ` Jeff Layton
2010-08-19 19:16       ` Jeff Layton
     [not found]       ` <20100819151618.5f769dc9-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-08-19 19:43         ` Trond Myklebust
2010-08-19 19:43           ` Trond Myklebust
2010-08-19 19:43           ` Trond Myklebust
2010-08-20 13:23           ` Wu Fengguang
2010-08-20 13:23             ` Wu Fengguang
2010-08-20 13:23             ` Wu Fengguang
2010-08-30 19:22             ` Trond Myklebust
2010-08-30 19:22               ` Trond Myklebust
2010-08-30 19:22               ` Trond Myklebust
2010-08-30 23:53               ` Wu Fengguang
2010-08-30 23:53                 ` Wu Fengguang
2010-08-20  0:33       ` Wu Fengguang
2010-08-20  0:33         ` Wu Fengguang
2010-08-20  0:53         ` Jeff Layton
2010-08-20  0:53           ` Jeff Layton
2010-08-20 13:20           ` Wu Fengguang
2010-08-20 13:20             ` Wu Fengguang
2010-08-19 23:55   ` Wu Fengguang
2010-08-19 23:55     ` Wu Fengguang
2010-08-20  0:02     ` Wu Fengguang
2010-08-20  0:02       ` Wu Fengguang
2010-08-20  2:36       ` Sage Weil
2010-08-20  2:36         ` Sage Weil
2010-08-20  9:19     ` Christoph Hellwig
2010-08-20  9:19       ` Christoph Hellwig
2010-08-20 11:27       ` Jeff Layton
2010-08-20 11:27         ` Jeff Layton
2010-08-20 11:27         ` Jeff Layton
2010-08-20 12:44         ` Wu Fengguang [this message]
2010-08-20 12:44           ` Wu Fengguang
2010-08-20 12:26       ` Wu Fengguang
2010-08-20 12:26         ` Wu Fengguang
2010-08-20 12:26         ` Wu Fengguang

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=20100820124424.GA17022@localhost \
    --to=fengguang.wu@gmail.com \
    --cc=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@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 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.