From: Matthew Wilcox <willy@infradead.org>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jeff Layton <jlayton@kernel.org>,
Ilya Dryomov <idryomov@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
linux-mm@kvack.org, linux-nfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] nfs: remove reliance on bdi congestion
Date: Mon, 31 Jan 2022 04:22:34 +0000 [thread overview]
Message-ID: <YfdkCsxyu0jpo+98@casper.infradead.org> (raw)
In-Reply-To: <164360183350.4233.691070075155620959.stgit@noble.brown>
On Mon, Jan 31, 2022 at 03:03:53PM +1100, NeilBrown wrote:
> - .writepage to return AOP_WRITEPAGE_ACTIVATE if WB_SYNC_NONE
> and the flag is set.
Is this actually useful? I ask because Dave Chinner believes
the call to ->writepage in vmscan to be essentially unused.
See commit 21b4ee7029c9, and I had a followup discussion with him
on IRC:
<willy> dchinner: did you gather any stats on how often ->writepage was
being called by pageout() before "xfs: drop ->writepage completely"
was added?
<dchinner> willy: Never saw it on XFS in 3 years in my test environment...
<dchinner> I don't ever recall seeing the memory reclaim guards we put on
->writepage in XFS ever firing - IIRC they'd been there for the best
part of a decade.
<willy> not so much the WARN_ON firing but the case where it actually calls
iomap_writepage
<dchinner> willy: I mean both - I was running with a local patch that warned
on writepage for a long time, regardless of where it was called from.
I can believe things are different for a network filesystem, or maybe
XFS does background writeback better than other filesystems, but it
would be intriguing to be able to get rid of ->writepage altogether
(or at least from pageout(); migrate.c may be a thornier proposition).
next prev parent reply other threads:[~2022-01-31 4:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 4:03 [PATCH 0/3] remove dependence of inode_congested() NeilBrown
2022-01-31 4:03 ` [PATCH 1/3] fuse: remove reliance on bdi congestion NeilBrown
2022-01-31 4:28 ` Matthew Wilcox
2022-01-31 4:47 ` NeilBrown
2022-01-31 10:21 ` Miklos Szeredi
2022-01-31 13:12 ` Matthew Wilcox
2022-01-31 23:00 ` NeilBrown
2022-02-01 2:01 ` Matthew Wilcox
2022-02-01 3:28 ` NeilBrown
2022-02-01 4:06 ` Matthew Wilcox
2022-02-07 0:47 ` NeilBrown
2022-01-31 4:03 ` [PATCH 3/3] ceph: " NeilBrown
2022-01-31 4:03 ` [PATCH 2/3] nfs: " NeilBrown
2022-01-31 4:22 ` Matthew Wilcox [this message]
2022-01-31 4:55 ` NeilBrown
2022-01-31 13:15 ` Matthew Wilcox
2022-01-31 21:38 ` NeilBrown
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=YfdkCsxyu0jpo+98@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=anna.schumaker@netapp.com \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=trond.myklebust@hammerspace.com \
/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.