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;
Date:   Tue, 7 Sep 2021 11:39:44 -0400
From:   Bruce Fields <bfields@fieldses.org>
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Neil Brown <neilb@suse.de>, Matthew Wilcox <willy@infradead.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()
Message-ID: <20210907153944.GA1364@fieldses.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8ED6E493-21A6-46BC-810A-D9DA42996979@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Tue, Sep 07, 2021 at 02:53:48PM +0000, 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.

Give up parallelism in return for at least hope of forward progress?
(Which should be possible as long as there's at least one server
thread.)

--b.