From patchwork Wed Mar 10 10:46:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mel Gorman X-Patchwork-Id: 12127709 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=-11.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT 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 EFD77C433E6 for ; Wed, 10 Mar 2021 10:46:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 570F364F7F for ; Wed, 10 Mar 2021 10:46:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 570F364F7F 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 E1A438D0192; Wed, 10 Mar 2021 05:46:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C78C38D0197; Wed, 10 Mar 2021 05:46:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF1388D0148; Wed, 10 Mar 2021 05:46:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id 8A7288D0192 for ; Wed, 10 Mar 2021 05:46:22 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5108882499A8 for ; Wed, 10 Mar 2021 10:46:22 +0000 (UTC) X-FDA: 77903635404.24.56A7806 Received: from outbound-smtp22.blacknight.com (outbound-smtp22.blacknight.com [81.17.249.190]) by imf22.hostedemail.com (Postfix) with ESMTP id 5E55AC0001FA for ; Wed, 10 Mar 2021 10:46:18 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp22.blacknight.com (Postfix) with ESMTPS id 28A61BAC7D for ; Wed, 10 Mar 2021 10:46:19 +0000 (GMT) Received: (qmail 23771 invoked from network); 10 Mar 2021 10:46:19 -0000 Received: from unknown (HELO stampy.112glenside.lan) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPA; 10 Mar 2021 10:46:18 -0000 From: Mel Gorman To: Andrew Morton Cc: Chuck Lever , Jesper Dangaard Brouer , Christoph Hellwig , LKML , Linux-Net , Linux-MM , Linux-NFS , Mel Gorman Subject: [PATCH 0/5] Introduce a bulk order-0 page allocator with two in-tree users Date: Wed, 10 Mar 2021 10:46:13 +0000 Message-Id: <20210310104618.22750-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 X-Stat-Signature: 111sxcynwik5nh19ohxf56us9uptt1nn X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5E55AC0001FA Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=outbound-smtp22.blacknight.com; client-ip=81.17.249.190 X-HE-DKIM-Result: none/none X-HE-Tag: 1615373178-831246 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: Changelog since v1 o Parenthesise binary and boolean comparisons o Add reviewed-bys o Rebase to 5.12-rc2 This series introduces a bulk order-0 page allocator with sunrpc and the network page pool being the first users. 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. Improving the implementation requires fairly deep surgery in numerous places. The lock scope would need to be significantly reduced, particularly as vmstat, per-cpu and the buddy allocator have different locking protocol that overall -- e.g. all partially depend on irqs being disabled at various points. Secondly, the core of the allocator deals with single pages where as both the bulk allocator and per-cpu allocator operate in batches. All of that has to be reconciled with all the existing users and their constraints (memory offline, CMA and cpusets being the trickiest). Light testing passed, I'm relying on Chuck and Jesper to test the target users more aggressively but both report performance improvements with the initial RFC. Patch 1 of this series is a cleanup to sunrpc, it could be merged separately but is included here as a pre-requisite. Patch 2 is the prototype bulk allocator Patch 3 is the sunrpc user. Chuck also has a patch which further caches pages but is not included in this series. It's not directly related to the bulk allocator and as it caches pages, it might have other concerns (e.g. does it need a shrinker?) Patch 4 is a preparation patch only for the network user Patch 5 converts the net page pool to the bulk allocator for order-0 pages. There is no obvious impact to the existing paths as only new users of the API should notice a difference between multiple calls to the allocator and a single bulk allocation. include/linux/gfp.h | 13 +++++ mm/page_alloc.c | 113 +++++++++++++++++++++++++++++++++++++++++- net/core/page_pool.c | 102 +++++++++++++++++++++++--------------- net/sunrpc/svc_xprt.c | 47 ++++++++++++------ 4 files changed, 220 insertions(+), 55 deletions(-)