From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45597C433EF for ; Tue, 7 Sep 2021 15:41:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 023CD60698 for ; Tue, 7 Sep 2021 15:41:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 023CD60698 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 469C06B0071; Tue, 7 Sep 2021 11:41:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 418B2900002; Tue, 7 Sep 2021 11:41:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 308F46B0073; Tue, 7 Sep 2021 11:41:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 20F8C6B0071 for ; Tue, 7 Sep 2021 11:41:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C9572181AEF31 for ; Tue, 7 Sep 2021 15:41:31 +0000 (UTC) X-FDA: 78561191982.29.06AC1FB Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf06.hostedemail.com (Postfix) with ESMTP id 56977801A89C for ; Tue, 7 Sep 2021 15:41:31 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 05FC9220F4; Tue, 7 Sep 2021 15:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1631029290; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lqHb/tASQGnJarzZC0qa6X3H0t7+vPi6wKd0G7SrSQk=; b=Sgzrx7k46UnY0HskaR3CVgatBNQwnReCXRE8RlzRkCILhZcfFFeQgTImrKYORhuP72rFYG G36IgDIAsabbaJAEr2xwkTqubboU0PFmjOBJgbX49+N1BM5nTTWZnIovqVSOb8GYkTUrnB F85XgALWR9DlGUz/LX79/qpt8Ke1zlE= Received: from suse.com (mgorman.udp.ovpn2.nue.suse.de [10.163.43.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A4F98A3B81; Tue, 7 Sep 2021 15:41:29 +0000 (UTC) Date: Tue, 7 Sep 2021 16:41:25 +0100 From: Mel Gorman To: Chuck Lever III Cc: Neil Brown , Matthew Wilcox , Bruce Fields , Linux NFS Mailing List , Linux-MM Subject: Re: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args() Message-ID: <20210907153116.GJ3828@suse.com> References: <163090344807.19339.10071205771966144716@noble.neil.brown.name> <848A6498-CFF3-4C66-AE83-959F8221E930@oracle.com> <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=iso-8859-15 Content-Disposition: inline In-Reply-To: <8ED6E493-21A6-46BC-810A-D9DA42996979@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Sgzrx7k4; spf=pass (imf06.hostedemail.com: domain of mgorman@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Stat-Signature: qttu8c5amrdfapkamtwapp6qhqnqbrqr X-Rspamd-Queue-Id: 56977801A89C X-Rspamd-Server: rspam04 X-HE-Tag: 1631029291-800167 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 07, 2021 at 02:53:48PM +0000, Chuck Lever III wrote: > > 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?). > Don't use NOFAIL. It's intended for allocation requests that if they fail, there is no sane way for the kernel to recover. Amoung other things, it can access emergency memory reserves and if not returned quickly may cause premature OOM or even a livelock. > The question in my mind is how the new alloc_pages_bulk() will > behave when passed NOFAIL. I would expect that NOFAIL would simply > guarantee that at least one page is allocated on every call. > alloc_pages_bulk ignores GFP_NOFAIL. If called repeatedly, it might pass the GFP_NOFAIL flag to allocate at least one page but you'll be depleting reserves to do it from a call site that has other options for recovery. The docs say it better * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures. The allocation could block * indefinitely but will never return with failure. Testing for * failure is pointless. * New users should be evaluated carefully (and the flag should be * used only when there is no reasonable failure policy) but it is * definitely preferable to use the flag rather than opencode endless * loop around allocator. * Using this flag for costly allocations is _highly_ discouraged -- Mel Gorman SUSE Labs