Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3286850pxb; Mon, 6 Sep 2021 17:45:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVbPZo46sXj/+ZGYk8Ze0nr4kDh/5YTKd5WteCB/qgJwXU8m4QG9TQP/zAGbbfTwf0owbd X-Received: by 2002:a05:6638:4122:: with SMTP id ay34mr13082513jab.131.1630975509538; Mon, 06 Sep 2021 17:45:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630975509; cv=none; d=google.com; s=arc-20160816; b=V3mQmoRO1gKstuTa7+kULIfYH8nm2lNT8eWIFjILrmeBF+AifFqFKSQNTZPGz8XOoe hi/xH+W56qIDZtw5qyNILTGQ0v8F6c1OnVAmCXuE9lr8LxoHc+mxJiNKtvQRh8C/m1MH AkhthGwYo1X7UIoEGxbQbauLDGbrnCWgI05z+mU/WxzHYjJ4AaaeYS/dDOtq7Oe7IlaF Z4qYdpZmPDoaKTyvTfsflGnJ13c2HmfzD6Rl10ghVqnALtZcWbW2J23vq8yRE80IYaJN uRQcwSI1tJBP8j1FUuzQTGU3VrzK/iLzd1EurrbyHZD2TsT6iSoxGGALpy1FodRgh9Hj tNkA== 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=OAW130kfzXgD7DFHMInOZ8+8a98c4xfyHi7BgBKUqgU=; b=iJotwmeezmbOUIdix36j8Vfd2dJrDMnStB1+UjOwbkZODc6d1LGyyp/GHar/iP4dI5 oSkz0YWWMBFTXw9Gdxt7pnq01JbQEwT6rXWoWcfp3A2IcXTmBgFxKiw0a36t3oHFCSUz LyFYk163x1vxp9PpL92pkyxVK6jdpKfQyt7CuGsYXq+0/s6i9H931z0T+uEuqYtKzDFo M+0Rz2uiHgM8+qY8pnFyb5zUjmAM2F5K4UTsxHIdEBAyGoohHdEKyUrU7JlfQa04EOzW qSWVc5QZ24e5UKwO5y9gDWAnEpF1O1e7ZYMu+erk4ER+IZPo2qxnZxR3NLrVEWS2p3nq UtGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=bWYy2jvS; dkim=neutral (no key) header.i=@suse.de; 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 h15si9290386ili.51.2021.09.06.17.44.43; Mon, 06 Sep 2021 17:45:09 -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=bWYy2jvS; dkim=neutral (no key) header.i=@suse.de; 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 S233598AbhIGAmp (ORCPT + 99 others); Mon, 6 Sep 2021 20:42:45 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:38816 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232659AbhIGAmo (ORCPT ); Mon, 6 Sep 2021 20:42:44 -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-out1.suse.de (Postfix) with ESMTPS id 87CA5221A8; Tue, 7 Sep 2021 00:41:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1630975298; 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=OAW130kfzXgD7DFHMInOZ8+8a98c4xfyHi7BgBKUqgU=; b=bWYy2jvSlF8VGXcaTp8MW+t9c2IyTP7QH1gv7APg+XcKF18ORbDWm6Rv7bWcbrCSs394IL Bhf9FTlpsCW16bctC/OrTQKqbcEN7ara5Tgf4rXXqkwffmtf0rzuo09wrHsFh0Z12Gflrw gEs29ACgpY9G3nUDI5Q4KwTe+YLE0K0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1630975298; 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=OAW130kfzXgD7DFHMInOZ8+8a98c4xfyHi7BgBKUqgU=; b=acWxfKIsn10FS691pHZ1KzL8IpyBAii4Ft8xw/pEqJcW2mV9mviIW5d9LNCVPBbXoZEJ8d VYYBFyX2IYWMhiAw== 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 AC5A413C31; Tue, 7 Sep 2021 00:41:36 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id EfhYGkC1NmGKbwAAMHmgww (envelope-from ); Tue, 07 Sep 2021 00:41:36 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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: <163096695999.2518.10383290668057550257@noble.neil.brown.name> References: <163090344807.19339.10071205771966144716@noble.neil.brown.name>, <848A6498-CFF3-4C66-AE83-959F8221E930@oracle.com>, , <163096695999.2518.10383290668057550257@noble.neil.brown.name> Date: Tue, 07 Sep 2021 10:41:33 +1000 Message-id: <163097529362.2518.16697605173806213577@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, 07 Sep 2021, NeilBrown wrote: > Even if we just provided > > void reclaim_progress_wait(void) > { > schedule_timeout_uninterruptible(HZ/20); > } > > that would be an improvement. I contemplated providing a patch, but the more I thought about it, the less sure I was. 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. 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. For the ext4_truncate case() that would be easier if there were a PF_MEMALLOC_NOFAIL flag though maybe passing down __GFP_MNOFAIL isn't too hard. (this is why we all work-around problems in the platform rather than fixing them. Fixing them is just too hard...) NeilBrown