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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 AD495C433E0 for ; Mon, 15 Feb 2021 12:06:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A09064E23 for ; Mon, 15 Feb 2021 12:06:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A09064E23 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 A40346B00FC; Mon, 15 Feb 2021 07:06:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EF706B00FE; Mon, 15 Feb 2021 07:06:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B7D56B00FF; Mon, 15 Feb 2021 07:06:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id 731A26B00FC for ; Mon, 15 Feb 2021 07:06:13 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3A2CF181F1003 for ; Mon, 15 Feb 2021 12:06:13 +0000 (UTC) X-FDA: 77820374226.15.crime07_440c7b72763b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 1306C1809A9AE for ; Mon, 15 Feb 2021 12:06:13 +0000 (UTC) X-HE-Tag: crime07_440c7b72763b X-Filterd-Recvd-Size: 6802 Received: from outbound-smtp14.blacknight.com (outbound-smtp14.blacknight.com [46.22.139.231]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Mon, 15 Feb 2021 12:06:11 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp14.blacknight.com (Postfix) with ESMTPS id 7313B1C3460 for ; Mon, 15 Feb 2021 12:06:10 +0000 (GMT) Received: (qmail 31181 invoked from network); 15 Feb 2021 12:06:10 -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); 15 Feb 2021 12:06:10 -0000 Date: Mon, 15 Feb 2021 12:06:09 +0000 From: Mel Gorman To: Chuck Lever Cc: Mel Gorman , Jesper Dangaard Brouer , Linux NFS Mailing List , "linux-mm@kvack.org" , Jakub Kicinski Subject: Re: alloc_pages_bulk() Message-ID: <20210215120608.GE3697@techsingularity.net> References: <2A0C36E7-8CB0-486F-A8DB-463CA28C5C5D@oracle.com> <20210209113108.1ca16cfa@carbon> <20210210084155.GA3697@techsingularity.net> <20210210124103.56ed1e95@carbon> <20210210130705.GC3629@suse.de> <20210211091235.GC3697@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Thu, Feb 11, 2021 at 04:20:31PM +0000, Chuck Lever wrote: > > On Feb 11, 2021, at 4:12 AM, Mel Gorman wrote: > > > > > > > > Parameters to __rmqueue_pcplist are garbage as the parameter order changed. > > I'm surprised it didn't blow up in a spectacular fashion. Again, this > > hasn't been near any testing and passing a list with high orders to > > free_pages_bulk() will corrupt lists too. Mostly it's a curiousity to see > > if there is justification for reworking the allocator to fundamentally > > deal in batches and then feed batches to pcp lists and the bulk allocator > > while leaving the normal GFP API as single page "batches". While that > > would be ideal, it's relatively high risk for regressions. There is still > > some scope for adding a basic bulk allocator before considering a major > > refactoring effort. > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index f8353ea7b977..8f3fe7de2cf7 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -5892,7 +5892,7 @@ __alloc_pages_bulk_nodemask(gfp_t gfp_mask, unsigned int order, > > pcp_list = &pcp->lists[migratetype]; > > > > while (nr_pages) { > > - page = __rmqueue_pcplist(zone, gfp_mask, migratetype, > > + page = __rmqueue_pcplist(zone, migratetype, alloc_flags, > > pcp, pcp_list); > > if (!page) > > break; > > The NFS server is considerably more stable now. Thank you! > Thanks for testing! > I confirmed that my patch is requesting and getting multiple pages. > The new NFSD code and the API seem to be working as expected. > > The results are stunning. Each svc_alloc_arg() call here allocates > 65 pages to satisfy a 256KB NFS READ request. > > Before: > > nfsd-972 [000] 584.513817: funcgraph_entry: + 35.385 us | svc_alloc_arg(); > nfsd-979 [002] 584.513870: funcgraph_entry: + 29.051 us | svc_alloc_arg(); > nfsd-980 [001] 584.513951: funcgraph_entry: + 29.178 us | svc_alloc_arg(); > nfsd-983 [000] 584.514014: funcgraph_entry: + 29.211 us | svc_alloc_arg(); > nfsd-976 [002] 584.514059: funcgraph_entry: + 29.315 us | svc_alloc_arg(); > nfsd-974 [001] 584.514127: funcgraph_entry: + 29.237 us | svc_alloc_arg(); > > After: > > nfsd-977 [002] 87.049425: funcgraph_entry: 4.293 us | svc_alloc_arg(); > nfsd-981 [000] 87.049478: funcgraph_entry: 4.059 us | svc_alloc_arg(); > nfsd-988 [001] 87.049549: funcgraph_entry: 4.474 us | svc_alloc_arg(); > nfsd-983 [003] 87.049612: funcgraph_entry: 3.819 us | svc_alloc_arg(); > nfsd-976 [000] 87.049619: funcgraph_entry: 3.869 us | svc_alloc_arg(); > nfsd-980 [002] 87.049738: funcgraph_entry: 4.124 us | svc_alloc_arg(); > nfsd-975 [000] 87.049769: funcgraph_entry: 3.734 us | svc_alloc_arg(); > Uhhhh, that is much better than I expected given how lame the implementation is. Sure -- it works, but it has more overhead than it should with the downside that reducing it requires fairly deep surgery. It may be enough to tidy this up to handle order-0 pages only to start with and see how far it gets. That's a fairly trivial modification. > There appears to be little cost change for single-page allocations > using the bulk allocator (nr_pages=1): > > Before: > > nfsd-985 [003] 572.324517: funcgraph_entry: 0.332 us | svc_alloc_arg(); > nfsd-986 [001] 572.324531: funcgraph_entry: 0.311 us | svc_alloc_arg(); > nfsd-985 [003] 572.324701: funcgraph_entry: 0.311 us | svc_alloc_arg(); > nfsd-986 [001] 572.324727: funcgraph_entry: 0.424 us | svc_alloc_arg(); > nfsd-985 [003] 572.324760: funcgraph_entry: 0.332 us | svc_alloc_arg(); > nfsd-986 [001] 572.324786: funcgraph_entry: 0.390 us | svc_alloc_arg(); > > After: > > nfsd-989 [002] 75.043226: funcgraph_entry: 0.322 us | svc_alloc_arg(); > nfsd-988 [001] 75.043436: funcgraph_entry: 0.368 us | svc_alloc_arg(); > nfsd-989 [002] 75.043464: funcgraph_entry: 0.424 us | svc_alloc_arg(); > nfsd-988 [001] 75.043490: funcgraph_entry: 0.317 us | svc_alloc_arg(); > nfsd-989 [002] 75.043517: funcgraph_entry: 0.425 us | svc_alloc_arg(); > nfsd-988 [001] 75.050025: funcgraph_entry: 0.407 us | svc_alloc_arg(); > That is not too surprising given that there would be some additional overhead to manage a list of 1 page. I would hope that users of the bulk allocator are not routinely calling it with nr_pages == 1. -- Mel Gorman SUSE Labs