Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2763264pxb; Tue, 9 Mar 2021 10:11:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJyyBj/U7ehvJGs8/XdfotMDBFrup97XROAZPCXpkUXcIHzn/5J61/EM99FZJm3jRGomHK/Q X-Received: by 2002:a17:906:66cc:: with SMTP id k12mr21244700ejp.382.1615313501573; Tue, 09 Mar 2021 10:11:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615313501; cv=none; d=google.com; s=arc-20160816; b=eKW3bIx/NLeixOii5BpQtdlyWVCGThwX9cVoGbdY3U+zEx9q5mJsNmUuu5P0JVLGP/ 61Pz+3XZ596wlUKOj34kbzd9qIgEA2ws8owEELvt97T/7T2EIYlEpbv8R2k5ln7JCxP+ majOGbGvK7Hb85IIQbZ8OO9HIhXdM7KisyCHaJQe7DsaPMe59MG6l2oFyBq4ngZqh31J mOcCSSnAPfj/Qy8pie0E6w1BFHrmvx0+hSo4qO4/q5/shb7RkDbl85bfVKi1vNhf1Hvl vbRIUctw1EL49VRi/Co8pupR7OS+eWTlPVtJnY/3S+9F9yyW2mQxeEiYWTUeP6SFe153 CPkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=apnbbXXp0PBGqJCWYzQ+QusVr27ht/HY5cDtyfCiwK8=; b=Dj/iQ4QBi93t34NEgF5Zi+US7faPMriH76x9nVyE7+q7eqQWCMLNOTpl7WLd3mex3+ xP0P1/63H3Zldf5mai/eLYkt39zgXaX9rw+u6I8+f1mD6sIGYUZ7yUcq9t0X4Y9jHkga +erTilH5u6si4CRVeZIoJktHTDhipd9t/Z6zfZ9yesLPSrwYaAtppMlvO/sjUyyF2dmD jslCFMtDkYwvEyBrGyF3m0C2qM3uX5KAqSkOWSWeIEa+A6MHK1NfFAba1kLl+CAEwxXy 72xqhLYdh7n7Sd7bpY1jqI7KdUV5JW6S8iXxvQso7f9HUfRPP1ZSRthVM0Tp7ej/TBsq oxBA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r21si9539099ejx.301.2021.03.09.10.11.07; Tue, 09 Mar 2021 10:11:41 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbhCISKe (ORCPT + 99 others); Tue, 9 Mar 2021 13:10:34 -0500 Received: from outbound-smtp44.blacknight.com ([46.22.136.52]:36041 "EHLO outbound-smtp44.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231904AbhCISKJ (ORCPT ); Tue, 9 Mar 2021 13:10:09 -0500 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp44.blacknight.com (Postfix) with ESMTPS id 1BF02F8824 for ; Tue, 9 Mar 2021 18:10:08 +0000 (GMT) Received: (qmail 21638 invoked from network); 9 Mar 2021 18:10:07 -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); 9 Mar 2021 18:10:07 -0000 Date: Tue, 9 Mar 2021 18:10:06 +0000 From: Mel Gorman To: Christoph Hellwig Cc: Andrew Morton , Chuck Lever , Jesper Dangaard Brouer , LKML , Linux-Net , Linux-MM , Linux-NFS Subject: Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator Message-ID: <20210309181006.GP3697@techsingularity.net> References: <20210301161200.18852-1-mgorman@techsingularity.net> <20210301161200.18852-3-mgorman@techsingularity.net> <20210309171230.GA198878@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20210309171230.GA198878@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Mar 09, 2021 at 05:12:30PM +0000, Christoph Hellwig wrote: > Would vmalloc be another good user of this API? > > > + /* May set ALLOC_NOFRAGMENT, fragmentation will return 1 page. */ > > + if (!prepare_alloc_pages(gfp_mask, 0, preferred_nid, nodemask, &ac, &alloc_mask, &alloc_flags)) > > This crazy long line is really hard to follow. > It's not crazier than what is already in alloc_pages_nodemask to share code. > > + return 0; > > + gfp_mask = alloc_mask; > > + > > + /* Find an allowed local zone that meets the high watermark. */ > > + for_each_zone_zonelist_nodemask(zone, z, ac.zonelist, ac.highest_zoneidx, ac.nodemask) { > > Same here. > Similar to what happens in get_page_from_freelist with the for_next_zone_zonelist_nodemask iterator. > > + unsigned long mark; > > + > > + if (cpusets_enabled() && (alloc_flags & ALLOC_CPUSET) && > > + !__cpuset_zone_allowed(zone, gfp_mask)) { > > + continue; > > + } > > No need for the curly braces. > Yes, but it's for coding style. MM has no hard coding style guidelines around this but for sched, it's generally preferred that if the "if" statement spans multiple lines then it should use {} even if the block is one line long for clarity. > > } > > > > - gfp_mask &= gfp_allowed_mask; > > - alloc_mask = gfp_mask; > > Is this change intentional? Yes so that prepare_alloc_pages works for both the single page and bulk allocator. Slightly less code duplication. -- Mel Gorman SUSE Labs