From: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Trond Myklebust
<trond.myklebust-41N18TsMXrtuMpJDpNschA@public.gmane.org>
Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
fengguang.wu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
chris.mason-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org
Subject: Re: why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ?
Date: Thu, 19 Aug 2010 11:24:08 -0400 [thread overview]
Message-ID: <20100819152408.GA29877@infradead.org> (raw)
In-Reply-To: <1282229905.6199.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On Thu, Aug 19, 2010 at 10:58:25AM -0400, Trond Myklebust wrote:
> To me that sounds fine. I've also been trying to wrap my head around the
> differences between 'nonblocking', 'for_background', 'for_reclaim' and
> 'for_kupdate' and how the filesystem is supposed to treat them.
Yeah, it's not clear to me either. for_background is in fact only used
in nfs, for the priority and the nfs_commit_inode flags, for_kupdate
is only used in nfs, and in a really weird spot in btrfs, and
for_reclaim is used in nfs, and two places in nilfs2 and in shmemfs.
> Aside from the above, I've used 'for_reclaim', 'for_kupdate' and
> 'for_background' in order to adjust the RPC request's queuing priority
> (high in the case of 'for_reclaim' and low for the other two).
Right now writepage calls to the filesystem can come from various
places:
- the flusher threads
- VM reclaim (kswapd, memcg, direct reclaim)
- memory migration
- filemap_fdatawrite & other calls directly from FS code, also
including fsync
We have WB_SYNC_ALL set for the second, data integrity pass when doing
a sync from the flusher threads, and when doing data integrity writes
from fs context (most fsync but also a few others). All these obviously
are high priority. It's not too easy to set priorities for the others
in my opinion.
--
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: Christoph Hellwig <hch@infradead.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Christoph Hellwig <hch@infradead.org>,
Jeff Layton <jlayton@redhat.com>,
fengguang.wu@gmail.com, linux-nfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
hughd@google.com, chris.mason@oracle.com,
konishi.ryusuke@lab.ntt.co.jp
Subject: Re: why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ?
Date: Thu, 19 Aug 2010 11:24:08 -0400 [thread overview]
Message-ID: <20100819152408.GA29877@infradead.org> (raw)
In-Reply-To: <1282229905.6199.19.camel@heimdal.trondhjem.org>
On Thu, Aug 19, 2010 at 10:58:25AM -0400, Trond Myklebust wrote:
> To me that sounds fine. I've also been trying to wrap my head around the
> differences between 'nonblocking', 'for_background', 'for_reclaim' and
> 'for_kupdate' and how the filesystem is supposed to treat them.
Yeah, it's not clear to me either. for_background is in fact only used
in nfs, for the priority and the nfs_commit_inode flags, for_kupdate
is only used in nfs, and in a really weird spot in btrfs, and
for_reclaim is used in nfs, and two places in nilfs2 and in shmemfs.
> Aside from the above, I've used 'for_reclaim', 'for_kupdate' and
> 'for_background' in order to adjust the RPC request's queuing priority
> (high in the case of 'for_reclaim' and low for the other two).
Right now writepage calls to the filesystem can come from various
places:
- the flusher threads
- VM reclaim (kswapd, memcg, direct reclaim)
- memory migration
- filemap_fdatawrite & other calls directly from FS code, also
including fsync
We have WB_SYNC_ALL set for the second, data integrity pass when doing
a sync from the flusher threads, and when doing data integrity writes
from fs context (most fsync but also a few others). All these obviously
are high priority. It's not too easy to set priorities for the others
in my opinion.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Christoph Hellwig <hch@infradead.org>,
Jeff Layton <jlayton@redhat.com>,
fengguang.wu@gmail.com, linux-nfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
hughd@google.com, chris.mason@oracle.com,
konishi.ryusuke@lab.ntt.co.jp
Subject: Re: why are WB_SYNC_NONE COMMITs being done with FLUSH_SYNC set ?
Date: Thu, 19 Aug 2010 11:24:08 -0400 [thread overview]
Message-ID: <20100819152408.GA29877@infradead.org> (raw)
In-Reply-To: <1282229905.6199.19.camel@heimdal.trondhjem.org>
On Thu, Aug 19, 2010 at 10:58:25AM -0400, Trond Myklebust wrote:
> To me that sounds fine. I've also been trying to wrap my head around the
> differences between 'nonblocking', 'for_background', 'for_reclaim' and
> 'for_kupdate' and how the filesystem is supposed to treat them.
Yeah, it's not clear to me either. for_background is in fact only used
in nfs, for the priority and the nfs_commit_inode flags, for_kupdate
is only used in nfs, and in a really weird spot in btrfs, and
for_reclaim is used in nfs, and two places in nilfs2 and in shmemfs.
> Aside from the above, I've used 'for_reclaim', 'for_kupdate' and
> 'for_background' in order to adjust the RPC request's queuing priority
> (high in the case of 'for_reclaim' and low for the other two).
Right now writepage calls to the filesystem can come from various
places:
- the flusher threads
- VM reclaim (kswapd, memcg, direct reclaim)
- memory migration
- filemap_fdatawrite & other calls directly from FS code, also
including fsync
We have WB_SYNC_ALL set for the second, data integrity pass when doing
a sync from the flusher threads, and when doing data integrity writes
from fs context (most fsync but also a few others). All these obviously
are high priority. It's not too easy to set priorities for the others
in my opinion.
--
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>
next prev parent reply other threads:[~2010-08-19 15:24 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 [this message]
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
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=20100819152408.GA29877@infradead.org \
--to=hch-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
--cc=chris.mason-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=fengguang.wu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=trond.myklebust-41N18TsMXrtuMpJDpNschA@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.