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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 AFD72C433DB for ; Mon, 22 Feb 2021 09:43:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2782264EDE for ; Mon, 22 Feb 2021 09:43:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2782264EDE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A42A76B0075; Mon, 22 Feb 2021 04:43:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F5AE6B0078; Mon, 22 Feb 2021 04:43:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 931E08D0001; Mon, 22 Feb 2021 04:43:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id 7DD1C6B0075 for ; Mon, 22 Feb 2021 04:43:00 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3956518014A12 for ; Mon, 22 Feb 2021 09:43:00 +0000 (UTC) X-FDA: 77845414920.24.C8DAF33 Received: from outbound-smtp47.blacknight.com (outbound-smtp47.blacknight.com [46.22.136.64]) by imf04.hostedemail.com (Postfix) with ESMTP id 652A1DE for ; Mon, 22 Feb 2021 09:42:58 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp47.blacknight.com (Postfix) with ESMTPS id 0AEDDFA9BE for ; Mon, 22 Feb 2021 09:42:58 +0000 (GMT) Received: (qmail 29662 invoked from network); 22 Feb 2021 09:42:57 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 22 Feb 2021 09:42:57 -0000 Date: Mon, 22 Feb 2021 09:42:56 +0000 From: Mel Gorman To: Jesper Dangaard Brouer Cc: Chuck Lever , Mel Gorman , Linux NFS Mailing List , "linux-mm@kvack.org" , Jakub Kicinski Subject: Re: alloc_pages_bulk() Message-ID: <20210222094256.GH3697@techsingularity.net> References: <20210209113108.1ca16cfa@carbon> <20210210084155.GA3697@techsingularity.net> <20210210124103.56ed1e95@carbon> <20210210130705.GC3629@suse.de> <20210211091235.GC3697@techsingularity.net> <20210211132628.1fe4f10b@carbon> <20210215120056.GD3697@techsingularity.net> <20210215171038.42f62438@carbon> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20210215171038.42f62438@carbon> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 652A1DE X-Stat-Signature: 7zkyniczw78kmr9zfjnz9io4piu5h8ua Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=outbound-smtp47.blacknight.com; client-ip=46.22.136.64 X-HE-DKIM-Result: none/none X-HE-Tag: 1613986978-763702 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, Feb 15, 2021 at 05:10:38PM +0100, Jesper Dangaard Brouer wrote: > > On Mon, 15 Feb 2021 12:00:56 +0000 > Mel Gorman wrote: > > > On Thu, Feb 11, 2021 at 01:26:28PM +0100, Jesper Dangaard Brouer wrote: > [...] > > > > > I also suggest the API can return less pages than requested. Because I > > > want to to "exit"/return if it need to go into an expensive code path > > > (like buddy allocator or compaction). I'm assuming we have a flags to > > > give us this behavior (via gfp_flags or alloc_flags)? > > > > > > > The API returns the number of pages returned on a list so policies > > around how aggressive it should be allocating the requested number of > > pages could be adjusted without changing the API. Passing in policy > > requests via gfp_flags may be problematic as most (all?) bits are > > already used. > > Well, I was just thinking that I would use GFP_ATOMIC instead of > GFP_KERNEL to "communicate" that I don't want this call to take too > long (like sleeping). I'm not requesting any fancy policy :-) > The NFS use case requires opposite semantics -- it really needs those allocations to succeed https://lore.kernel.org/r/161340498400.7780.962495219428962117.stgit@klimt.1015granger.net. I've asked what code it's based on as it's not 5.11 and I'll iron that out first. Then it might be clearer what the "can fail" semantics should look like. I think it would be best to have pairs of patches where the first patch adjusts the semantics of the bulk allocator and the second adds a user. That will limit the amount of code code carried in the implementation. When the initial users are in place then the implementation can be optimised as the optimisations will require significant refactoring and I not want to refactor multiple times. -- Mel Gorman SUSE Labs