Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Matthew Wilcox" <willy@infradead.org>,
        "Bruce Fields" <bfields@fieldses.org>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>,
        "Mel Gorman" <mgorman@suse.com>, "Linux-MM" <linux-mm@kvack.org>
Subject: Re: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args()
In-reply-to: <8ED6E493-21A6-46BC-810A-D9DA42996979@oracle.com>
References: <163090344807.19339.10071205771966144716@noble.neil.brown.name>,
 <848A6498-CFF3-4C66-AE83-959F8221E930@oracle.com>,
 <YTZ4E0Zh6F/WSpy0@casper.infradead.org>,
 <163096695999.2518.10383290668057550257@noble.neil.brown.name>,
 <163097529362.2518.16697605173806213577@noble.neil.brown.name>,
 <8ED6E493-21A6-46BC-810A-D9DA42996979@oracle.com>
Date:   Wed, 08 Sep 2021 07:47:43 +1000
Message-id: <163105126377.2518.15592120108305789302@noble.neil.brown.name>
Precedence: bulk

On Wed, 08 Sep 2021, Chuck Lever III wrote:
> 
> > On Sep 6, 2021, at 8:41 PM, NeilBrown <neilb@suse.de> wrote:
> > 
> > When does a single-page GFP_KERNEL allocation fail?  Ever?
> > 
> > I know that if I add __GFP_NOFAIL then it won't fail and that is
> > preferred to looping.
> > I know that if I add __GFP_RETRY_MAILFAIL (or others) then it might
> > fail.
> > But that is the semantics for a plain GFP_KERNEL ??
> > 
> > I recall a suggestion one that it would only fail if the process was
> > being killed by the oom killer.  That seems reasonable and would suggest
> > that retrying is really bad.  Is that true?
> > 
> > For svc_alloc_args(), it might be better to fail and have the calling
> > server thread exit.  This would need to be combined with dynamic
> > thread-count management so that when a request arrived, a new thread
> > might be started.
> 
> I don't immediately see a benefit to killing server threads
> during periods of memory exhaustion, but sometimes I lack
> imagination.


Dining philosophers problem.  If you cannot get all the resources you
need, a polite response is to release *all* the resources you have
before trying again.

> 
> 
> > So maybe we really don't want reclaim_progress_wait(), and all current
> > callers of congestion_wait() which are just waiting for allocation to
> > succeed should be either change to use __GFP_NOFAIL, or to handle
> > failure.
> 
> I had completely forgotten about GFP_NOFAIL. That seems like the
> preferred answer, as it avoids an arbitrary time-based wait for
> a memory resource. (And maybe svc_rqst_alloc() should also get
> the NOFAIL treatment?).

Apart from what others have said, GFP_NOFAIL is not appropriate for
svc_rqst_alloc() because it cannot honour kthread_stop().

NeilBrown