All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Wu Fengguang
	<fengguang.wu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Chris Mason <chris.mason-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Subject: Re: why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ?
Date: Fri, 20 Aug 2010 07:27:57 -0400	[thread overview]
Message-ID: <20100820072757.6ae9741a@tlielax.poochiereds.net> (raw)
In-Reply-To: <20100820091904.GB20138-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

On Fri, 20 Aug 2010 05:19:04 -0400
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Layton <jlayton@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Wu Fengguang <fengguang.wu@gmail.com>,
	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 07:27:57 -0400	[thread overview]
Message-ID: <20100820072757.6ae9741a@tlielax.poochiereds.net> (raw)
In-Reply-To: <20100820091904.GB20138@infradead.org>

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.

-- 
Jeff Layton <jlayton@redhat.com>

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Layton <jlayton@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Wu Fengguang <fengguang.wu@gmail.com>,
	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 07:27:57 -0400	[thread overview]
Message-ID: <20100820072757.6ae9741a@tlielax.poochiereds.net> (raw)
In-Reply-To: <20100820091904.GB20138@infradead.org>

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.

-- 
Jeff Layton <jlayton@redhat.com>

--
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>

  parent reply	other threads:[~2010-08-20 11:27 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
     [not found] ` <20100819101525.076831ad-xSBYVWDuneFaJnirhKH9O4GKTjYczspe@public.gmane.org>
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
     [not found]       ` <1282229905.6199.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
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
     [not found]               ` <1282246999.7799.66.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
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
     [not found]         ` <20100820091904.GB20138-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2010-08-20 11:27           ` Jeff Layton [this message]
2010-08-20 11:27             ` Jeff Layton
2010-08-20 11:27             ` Jeff Layton
2010-08-20 12:44             ` Wu Fengguang
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=20100820072757.6ae9741a@tlielax.poochiereds.net \
    --to=jlayton-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=chris.mason-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=fengguang.wu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.