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=-5.8 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 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 7AE1DC433F5 for ; Tue, 7 Sep 2021 00:41:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E23A4610A3 for ; Tue, 7 Sep 2021 00:41:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E23A4610A3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id EF3B56B0071; Mon, 6 Sep 2021 20:41:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA3E36B0072; Mon, 6 Sep 2021 20:41:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1BE1900002; Mon, 6 Sep 2021 20:41:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id C1DF86B0071 for ; Mon, 6 Sep 2021 20:41:40 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5959E181AEF31 for ; Tue, 7 Sep 2021 00:41:40 +0000 (UTC) X-FDA: 78558924360.40.53EF896 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id E1B6310000A3 for ; Tue, 7 Sep 2021 00:41:39 +0000 (UTC) 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> Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=bWYy2jvS; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=acWxfKIs; spf=pass (imf12.hostedemail.com: domain of neilb@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Stat-Signature: tdjaga3igo58pzby4pyne1qcx9xpr937 X-Rspamd-Queue-Id: E1B6310000A3 X-Rspamd-Server: rspam04 X-HE-Tag: 1630975299-382743 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, 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