On Tue, 07 Sep 2021, Matthew Wilcox wrote: > On Mon, Sep 06, 2021 at 03:46:34PM +0000, Chuck Lever III wrote: > > Hi Neil- > > > > > On Sep 6, 2021, at 12:44 AM, NeilBrown <neilb@xxxxxxx> wrote: > > > > > > > > > Many places that need to wait before retrying a memory allocation use > > > congestion_wait(). xfs_buf_alloc_pages() is a good example which > > > follows a similar pattern to that in svc_alloc_args(). > > > > > > It make sense to do the same thing in svc_alloc_args(); This will allow > > > the allocation to be retried sooner if some backing device becomes > > > non-congested before the timeout. > > It's adorable that you believe this is still true. always happy to be called "adorable" !! > > https://lore.kernel.org/linux-mm/20191231125908.GD6788@xxxxxxxxxxxxxxxxxxxxxx/ > > Interesting ... a few filesystems call clear_bdi_congested(), but not enough to make a difference. At least my patch won't make things worse. And when (not if !!) congestion_wait() gets fixed, sunrpc will immediately benefit. I suspect that "congestion_wait()" needs to be replaced by several different interfaces. Some callers want to wait until memory might be available, which should be tracked entirely by MM, not by filesystems. Other caller are really only interested in their own bdi making progress and should be allowed to specify that bdi. And in general, it seems that that waits aren't really interested in congestion being eased, but in progress being made. reclaim_progress_wait() bdi_progress_wait() ?? Even if we just provided void reclaim_progress_wait(void) { schedule_timeout_uninterruptible(HZ/20); } that would be an improvement. It could be called from svc_alloc_args() and various other places that want to wait before retrying an allocation, and it would be no worse than current behaviour. Then if anyone had a clever idea of how to get a notification when progress had been made, there would be an obvious place to implement that idea. NeilBrown
