On Mon, 13 Dec 2021, Dave Chinner wrote:

On Mon, Dec 13, 2021 at 03:14:27PM +1100, NeilBrown wrote:

quoted

These functions are no longer useful as the only bdis that report
congestion are in ceph, fuse, and nfs.  None of those bdis can be the
target of the calls in drbd, ext2, nilfs2, or xfs.

Removing the test on bdi_write_contested() in current_may_throttle()
could cause a small change in behaviour, but only when PF_LOCAL_THROTTLE
is set.

So replace the calls by 'false' and simplify the code - and remove the
functions.

Signed-off-by: NeilBrown <redacted>

....

quoted

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 631c5a61d89b..22f73b3e888e 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c

@@ -843,9 +843,6 @@ xfs_buf_readahead_map(
 {
 	struct xfs_buf		*bp;
 
-	if (bdi_read_congested(target->bt_bdev->bd_disk->bdi))
-		return;

Ok, but this isn't a "throttle writeback" test here - it's trying to
avoid having speculative readahead blocking on a full request queue
instead of just skipping the readahead IO. i.e. prevent readahead
thrashing and/or adding unnecessary read load when we already have a
full read queue...

So what is the replacement for that? We want to skip the entire
buffer lookup/setup/read overhead if we're likely to block on IO
submission - is there anything we can use to do this these days?

I don't think there is a concept of a "full read queue" any more.
There are things that can block an IO submission though.
There is allocation of the bio from a mempool, and there is
rq_qos_throttle, and there are probably other places where submission
can block.  I don't think you can tell in advance if a submission is
likely to block.

I think the idea is that the top level of the submission stack should
rate-limit based on the estimated throughput of the stack.  I think
write-back does this.  I don't know about read-ahead.

NeilBrown