linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.com>
To: NeilBrown <neilb@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>,
	Chuck Lever III <chuck.lever@oracle.com>,
	Bruce Fields <bfields@fieldses.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args()
Date: Tue, 7 Sep 2021 09:17:18 +0100	[thread overview]
Message-ID: <20210907081718.GG3828@suse.com> (raw)
In-Reply-To: <163096695999.2518.10383290668057550257@noble.neil.brown.name>

On Tue, Sep 07, 2021 at 08:22:39AM +1000, NeilBrown wrote:
> 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@suse.de> 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@bombadil.infradead.org/
> > 
> > 
> 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.
> 

For the available memory side, I believe the interface would involve a
waitqueue combined with something like struct capture_control except it
has a waitqueue, a zone, an order, a struct page pointer and a list_head
that is declared on stack. Reclaimers for that zone would check if there
are any such waiters and if so, add a page that has just being reclaimed
and wake the waiter.

That then would be more event driven than time driven which is usually
what mm is meant to do. Despite congestion_wait being known to be broken
for a long time, I don't recall anyone trying to actually fix it.

> 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);
>  }
> 

reclaim_progress_wait at least would clarify that it's waiting on a page
but ultimately, it shouldn't be time based.

-- 
Mel Gorman
SUSE Labs

  parent reply	other threads:[~2021-09-07  8:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06  4:44 [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args() NeilBrown
2021-09-06 15:46 ` Chuck Lever III
2021-09-06 20:20   ` Matthew Wilcox
2021-09-06 22:13     ` Bruce Fields
2021-09-06 22:22     ` NeilBrown
2021-09-07  0:41       ` NeilBrown
2021-09-07 14:53         ` Chuck Lever III
2021-09-07 15:39           ` Bruce Fields
2021-09-07 15:41           ` Mel Gorman
2021-09-07 16:21             ` Chuck Lever III
2021-09-07 21:47           ` NeilBrown
2021-09-07  8:17       ` Mel Gorman [this message]
2021-09-06 21:52   ` 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=20210907081718.GG3828@suse.com \
    --to=mgorman@suse.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).