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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 3DAD2C433E0 for ; Thu, 11 Mar 2021 08:48:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9FE3264FAA for ; Thu, 11 Mar 2021 08:48:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FE3264FAA 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 1E0518D0296; Thu, 11 Mar 2021 03:48:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 190708D028E; Thu, 11 Mar 2021 03:48:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 009ED8D0296; Thu, 11 Mar 2021 03:48:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id D51D08D028E for ; Thu, 11 Mar 2021 03:48:30 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9C3162496 for ; Thu, 11 Mar 2021 08:48:30 +0000 (UTC) X-FDA: 77906967180.05.66790BC Received: from outbound-smtp53.blacknight.com (outbound-smtp53.blacknight.com [46.22.136.237]) by imf24.hostedemail.com (Postfix) with ESMTP id 140ECA0009E9 for ; Thu, 11 Mar 2021 08:48:25 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp53.blacknight.com (Postfix) with ESMTPS id 9892F640B9 for ; Thu, 11 Mar 2021 08:48:28 +0000 (GMT) Received: (qmail 19459 invoked from network); 11 Mar 2021 08:48:28 -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); 11 Mar 2021 08:48:28 -0000 Date: Thu, 11 Mar 2021 08:48:27 +0000 From: Mel Gorman To: Andrew Morton Cc: Chuck Lever , Jesper Dangaard Brouer , Christoph Hellwig , LKML , Linux-Net , Linux-MM , Linux-NFS Subject: Re: [PATCH 0/5] Introduce a bulk order-0 page allocator with two in-tree users Message-ID: <20210311084827.GS3697@techsingularity.net> References: <20210310104618.22750-1-mgorman@techsingularity.net> <20210310154704.9389055d0be891a0c3549cc2@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20210310154704.9389055d0be891a0c3549cc2@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 140ECA0009E9 X-Stat-Signature: uzsutshywuwehfu7myzbs8e17k873jq9 Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=outbound-smtp53.blacknight.com; client-ip=46.22.136.237 X-HE-DKIM-Result: none/none X-HE-Tag: 1615452505-812103 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 Wed, Mar 10, 2021 at 03:47:04PM -0800, Andrew Morton wrote: > On Wed, 10 Mar 2021 10:46:13 +0000 Mel Gorman wrote: > > > This series introduces a bulk order-0 page allocator with sunrpc and > > the network page pool being the first users. > > > > Right now, the [0/n] doesn't even tell us that it's a performance > patchset! > I'll add a note about this improving performance for users that operate on batches of patches and want to avoid multiple round-trips to the page allocator. > The whole point of this patchset appears to appear in the final paragraph > of the final patch's changelog. > I'll copy&paste that note to the introduction. It's likely that high-speed networking is the most relevant user in the short-term. > : For XDP-redirect workload with 100G mlx5 driver (that use page_pool) > : redirecting xdp_frame packets into a veth, that does XDP_PASS to create > : an SKB from the xdp_frame, which then cannot return the page to the > : page_pool. In this case, we saw[1] an improvement of 18.8% from using > : the alloc_pages_bulk API (3,677,958 pps -> 4,368,926 pps). > > Much more detail on the overall objective and the observed results, > please? > I cannot generate that data right now so I need Jesper to comment on exactly why this is beneficial. For example, while I get that more data can be processed in a microbenchmark, I do not have a good handle on how much difference that makes to a practical application. About all I know is that this problem has been knocking around for 3-4 years at least. > Also, that workload looks awfully corner-casey. How beneficial is this > work for more general and widely-used operations? > At this point, probably nothing for most users because batch page allocation is not common. It's primarily why I avoided reworking the whole allocator just to make this a bit tidier. > > The implementation is not > > particularly efficient and the intention is to iron out what the semantics > > of the API should have for users. Once the semantics are ironed out, it can > > be made more efficient. > > And some guesstimates about how much benefit remains to be realized > would be helpful. > I don't have that information unfortunately. It's a chicken and egg problem because without the API, there is no point creating new users. For example, fault around or readahead could potentially batch pages but whether it is actually noticable when page zeroing has to happen is a completely different story. It's a similar story for SLUB, we know lower order allocations hurt some microbenchmarks like hackbench-sockets but have not quantified what happens if SLUB batch allocates pages when high-order allocations fail. -- Mel Gorman SUSE Labs