Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3205899pxb; Mon, 6 Sep 2021 15:28:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzq+kN/SkB18f7UgitdbDZo+szART9CtKHuMtxYyiiwRcHXzQIdmXy+7fInvQhXyLyMqnZT X-Received: by 2002:a17:906:85da:: with SMTP id i26mr15717247ejy.163.1630967280025; Mon, 06 Sep 2021 15:28:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630967280; cv=none; d=google.com; s=arc-20160816; b=SLwS8LN/0uwyE5gW2XyK5lkzOh96ztop18FXSGySTV9ukXiBucKEz4tpWYD8gjuGEv XnlRsFPfTYAj6iw9wtv5SZLGfwUoCT9GWD6LjdZTREmWWxmCk2qpedVO59N65OE36Ai8 P3HBVVQjy3bCzwokH3wFQQbT8PFr03AYrBibsqdpb9PTiPvw42nJ4jXqlGlqC714zYlw yTDK4YhZOs6LLz9FG8I0IJlsoiqMKk4iwSeE412xkUbvM1dyFP4KLTPhs/I0eUVseq0c ItY8jn+m4asvAfiv106oT60D81xNbxLeHEvnjAm4Fwe8fCJzaNdzo8SMXOqW9X5UfAaN YJwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=Ry1NtczxOVERwJbS7sSrV/MZc1iO8yevRwTZtoL/ca4=; b=Guh/fqJTzRD3oamAf/TU9Db3ZRwdbjlyc0Xt26Oto3k+lMiYAknymozP4aBDZlzvA6 lRnWNgQV3/8h0lrORD4ELxjw9kJ0rNzEa7+VxBntSfruZS03gxcQE6+ZNge0yvxeKI22 UQc4emshZHh/9m0KnUtAXvmIfE1EEtyXWPSjirxwAoF5h64oCb3Ou8GHoY3gHVAjuFTV dphXRhdM/Iq53Vkl0wCqusonf7hnuK3WVIyXbsWQUxmn/SnHFIUlQnvrkOvCr4A7vaQj lmNyiaWEZmNz8WZ7tRSc6pjKOh+ek5vITOBZkXxa06KJD4PETAdK1eyYxyMa1hkNkCOX j1vQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=U7zUH81p; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sb9si9380782ejb.363.2021.09.06.15.27.36; Mon, 06 Sep 2021 15:28:00 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=U7zUH81p; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231948AbhIFWXu (ORCPT + 99 others); Mon, 6 Sep 2021 18:23:50 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:44346 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230384AbhIFWXu (ORCPT ); Mon, 6 Sep 2021 18:23:50 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 9C8971FF41; Mon, 6 Sep 2021 22:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1630966964; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ry1NtczxOVERwJbS7sSrV/MZc1iO8yevRwTZtoL/ca4=; b=U7zUH81pudjBE5twAiZMEOzEKHUvizWfa9sEflCH5nw45R9nobjHWzJ+1akVvGSYMX+Qni Ztm5Rz8eI8VZ74N7BUos0u/jzR/2SZEd87AoyOGh8Jd3PCILYtakVL5DDL8qqZG1OlW3w7 eJsW5UWFuuuMEwO5RcFJspCLs5OEUHM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1630966964; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ry1NtczxOVERwJbS7sSrV/MZc1iO8yevRwTZtoL/ca4=; b=1PDv2/lWBmO8DMw8BxQlN6XjFGtZJe93uO5gyaziIkHOOjRP+gfNCuPFrbfZJu5xsoCr4n A07UNGRZWnHwhyDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C66A713B73; Mon, 6 Sep 2021 22:22:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id nBkWIbKUNmGcVAAAMHmgww (envelope-from ); Mon, 06 Sep 2021 22:22:42 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Matthew Wilcox" Cc: "Chuck Lever III" , "Bruce Fields" , "Linux NFS Mailing List" , "Mel Gorman" , "Linux-MM" Subject: Re: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args() In-reply-to: References: <163090344807.19339.10071205771966144716@noble.neil.brown.name>, <848A6498-CFF3-4C66-AE83-959F8221E930@oracle.com>, Date: Tue, 07 Sep 2021 08:22:39 +1000 Message-id: <163096695999.2518.10383290668057550257@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, 07 Sep 2021, Matthew Wilcox wrote: > On Mon, Sep 06, 2021 at 03:46:34PM +0000, Chuck Lever III wrote: > > Hi Neil- > >=20 > > > On Sep 6, 2021, at 12:44 AM, NeilBrown wrote: > > >=20 > > >=20 > > > 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(). > > >=20 > > > 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. >=20 > It's adorable that you believe this is still true. always happy to be called "adorable" !! >=20 > https://lore.kernel.org/linux-mm/20191231125908.GD6788@bombadil.infradead.o= rg/ >=20 >=20 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. 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); } that would be an improvement. It could be called from svc_alloc_args() and various other places that want to wait before retrying an allocation, and it would be no worse than current behaviour. Then if anyone had a clever idea of how to get a notification when progress had been made, there would be an obvious place to implement that idea. NeilBrown