[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegt-igF8HqsDUcMzfU0jYv8WpofLy0Uv0YnXLzsfx=tkGg@mail.gmail.com>
Date: Fri, 28 Jan 2022 10:37:56 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: NeilBrown <neilb@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
Jeff Layton <jlayton@...nel.org>,
Ilya Dryomov <idryomov@...il.com>,
Trond Myklebust <trond.myklebust@...merspace.com>,
Anna Schumaker <anna.schumaker@...app.com>,
Ryusuke Konishi <konishi.ryusuke@...il.com>,
"Darrick J. Wong" <djwong@...nel.org>,
Philipp Reisner <philipp.reisner@...bit.com>,
Lars Ellenberg <lars.ellenberg@...bit.com>,
Paolo Valente <paolo.valente@...aro.org>,
Jens Axboe <axboe@...nel.dk>, linux-mm <linux-mm@...ck.org>,
linux-nilfs@...r.kernel.org,
Linux NFS list <linux-nfs@...r.kernel.org>,
linux-fsdevel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
Ext4 <linux-ext4@...r.kernel.org>, ceph-devel@...r.kernel.org,
drbd-dev@...ts.linbit.com, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org
Subject: Re: [PATCH 1/9] Remove inode_congested()
On Thu, 27 Jan 2022 at 03:47, NeilBrown <neilb@...e.de> wrote:
>
> inode_congested() reports if the backing-device for the inode is
> congested. Few bdi report congestion any more, only ceph, fuse, and
> nfs. Having support just for those is unlikely to be useful.
>
> The places which test inode_congested() or it variants like
> inode_write_congested(), avoid initiating IO if congestion is present.
> We now have to rely on other places in the stack to back off, or abort
> requests - we already do for everything except these 3 filesystems.
>
> So remove inode_congested() and related functions, and remove the call
> sites, assuming that inode_congested() always returns 'false'.
Looks to me this is going to "break" fuse; e.g. readahead path will go
ahead and try to submit more requests, even if the queue is getting
congested. In this case the readahead submission will eventually
block, which is counterproductive.
I think we should *first* make sure all call sites are substituted
with appropriate mechanisms in the affected filesystems and as a last
step remove the superfluous bdi congestion mechanism.
You are saying that all fs except these three already have such
mechanisms in place, right? Can you elaborate on that?
Thanks,
Miklos
Powered by blists - more mailing lists