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 B5E94C433EF for ; Mon, 6 Sep 2021 22:13:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DE9B16108D for ; Mon, 6 Sep 2021 22:13:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DE9B16108D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fieldses.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 51465900002; Mon, 6 Sep 2021 18:13:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C4426B0072; Mon, 6 Sep 2021 18:13:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B201900002; Mon, 6 Sep 2021 18:13:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 291A96B0071 for ; Mon, 6 Sep 2021 18:13:23 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D64BE2BC16 for ; Mon, 6 Sep 2021 22:13:22 +0000 (UTC) X-FDA: 78558550644.18.5376AFD Received: from fieldses.org (fieldses.org [173.255.197.46]) by imf15.hostedemail.com (Postfix) with ESMTP id 46223D000099 for ; Mon, 6 Sep 2021 22:13:22 +0000 (UTC) Received: by fieldses.org (Postfix, from userid 2815) id CD59B1C25; Mon, 6 Sep 2021 18:13:20 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org CD59B1C25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1630966400; bh=7qQ1YEVuELfcLLU6rsSG8Nh0MZtTiMr8wJzVl4dRIAQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EOBrzpDls2e2ejFaU6ueSxh7P6fih8qiwmDCJvV1xKw2D95fFJ+5/tz7cw9Bisba9 ihPH+khC4YtqAquYl+rDbCbppfG3dQRC3ttf74sN18SK7JGwG15Rd8TnqnUPEqkylf NxRmWaJ0m0IQLi23GtmM3D3Yt6vn7P+Hvj0XdOio= Date: Mon, 6 Sep 2021 18:13:20 -0400 From: Bruce Fields To: Matthew Wilcox Cc: Chuck Lever III , Neil Brown , Linux NFS Mailing List , Mel Gorman , Linux-MM Subject: Re: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args() Message-ID: <20210906221320.GA21567@fieldses.org> References: <163090344807.19339.10071205771966144716@noble.neil.brown.name> <848A6498-CFF3-4C66-AE83-959F8221E930@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 46223D000099 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=fieldses.org header.s=default header.b=EOBrzpDl; dmarc=none; spf=pass (imf15.hostedemail.com: domain of bfields@fieldses.org designates 173.255.197.46 as permitted sender) smtp.mailfrom=bfields@fieldses.org X-Rspamd-Server: rspam01 X-Stat-Signature: z44gcxyz7gncorkw91rgui6rgbdm1dx8 X-HE-Tag: 1630966402-754485 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 Mon, Sep 06, 2021 at 09:20:35PM +0100, 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 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. > > https://lore.kernel.org/linux-mm/20191231125908.GD6788@bombadil.infradead.org/ So, what's the advice for now? Do we add the congestion_wait() call anyway and assume it'll be fixed to do something less broken in the future, or just skip it completely? --b.