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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47806C4332F for ; Tue, 5 Oct 2021 09:16:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CF5FD61425 for ; Tue, 5 Oct 2021 09:16:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CF5FD61425 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3D0B56B006C; Tue, 5 Oct 2021 05:16:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3805C6B0071; Tue, 5 Oct 2021 05:16:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24868900002; Tue, 5 Oct 2021 05:16:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id 12C2B6B006C for ; Tue, 5 Oct 2021 05:16:08 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B234018297714 for ; Tue, 5 Oct 2021 09:16:07 +0000 (UTC) X-FDA: 78661827174.11.AEEE747 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf10.hostedemail.com (Postfix) with ESMTP id 1E1186002B86 for ; Tue, 5 Oct 2021 09:16:06 +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 D14BF222E2; Tue, 5 Oct 2021 09:16:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1633425365; 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=/ThOmbiGRYKn2nnNwyvJcqEVvTNtr1GRMmAy+3vp6S8=; b=N+YuAsS0RWIkK8xSiaVHWPrcFj6Vkw5RjrUbcXkNWatj1zS9tp7bJ2LIFCYBeBqvSsEYUH /iTUxFMrteXb9ipCsAvKDk9+1W+Nqo6ARm5jzX8teZhaVWsLbm81JkgtrPB5gyjIPCacgj iPyurgn4Fdd7QHkVFLiT5BYKQSa7fCc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1633425365; 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=/ThOmbiGRYKn2nnNwyvJcqEVvTNtr1GRMmAy+3vp6S8=; b=df+BMW9OkAfq6YBbymxZbcDCld7xAbE3FMddRc4PnOqTXLGNmbzwPjAM4RDqkYJhHIdqra 4wCAPW6bQiQkJ6AQ== 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 8C631133A7; Tue, 5 Oct 2021 09:16:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id rLeKIdUXXGGuegAAMHmgww (envelope-from ); Tue, 05 Oct 2021 09:16:05 +0000 Message-ID: <60ffc506-236c-faf7-ba64-5d853d3a67e7@suse.cz> Date: Tue, 5 Oct 2021 11:16:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Content-Language: en-US To: Mel Gorman , NeilBrown Cc: Andrew Morton , Theodore Ts'o , Andreas Dilger , "Darrick J. Wong" , Matthew Wilcox , Michal Hocko , Jesper Dangaard Brouer , ". Dave Chinner" , Jonathan Corbet , linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org References: <163184698512.29351.4735492251524335974.stgit@noble.brown> <163184741776.29351.3565418361661850328.stgit@noble.brown> <20210917144233.GD3891@suse.de> From: Vlastimil Babka Subject: Re: [PATCH 1/6] MM: Support __GFP_NOFAIL in alloc_pages_bulk_*() and improve doco In-Reply-To: <20210917144233.GD3891@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=N+YuAsS0; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=df+BMW9O; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1E1186002B86 X-Stat-Signature: 6qe7ts6xadab44tj4qyd5meiw6ra57my X-HE-Tag: 1633425366-607947 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 9/17/21 16:42, Mel Gorman wrote: > I'm top-posting to cc Jesper with full context of the patch. I don't > have a problem with this patch other than the Fixes: being a bit > marginal, I should have acked as Mel Gorman and the > @gfp in the comment should have been @gfp_mask. > > However, an assumption the API design made was that it should fail fast > if memory is not quickly available but have at least one page in the > array. I don't think the network use case cares about the situation where > the array is already populated but I'd like Jesper to have the opportunity > to think about it. It's possible he would prefer it's explicit and the > check becomes > (!nr_populated || ((gfp_mask & __GFP_NOFAIL) && !nr_account)) to Note that AFAICS nr_populated is an incomplete piece of information, as we initially only count pages in the page_array as nr_populated up to the first NULL pointer. So even before Neil's patch we could decide to allocate even if there are pre-existing pages, but placed later in the array. Which could be rather common if the array consumer starts from index 0? So with Neil's patch this at least becomes consistent, while the check suggested by Mel leaves there the weird dependency on where pre-existing pages appear in the page_array.