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=-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 EC3CDC433DB for ; Wed, 24 Feb 2021 10:26:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E50964EC9 for ; Wed, 24 Feb 2021 10:26:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E50964EC9 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 9A3736B006C; Wed, 24 Feb 2021 05:26:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 94B7C6B0071; Wed, 24 Feb 2021 05:26:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F76A6B006C; Wed, 24 Feb 2021 05:26:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id 681986B006C for ; Wed, 24 Feb 2021 05:26:06 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2DFCB8248047 for ; Wed, 24 Feb 2021 10:26:06 +0000 (UTC) X-FDA: 77852781132.03.726EC5E Received: from outbound-smtp34.blacknight.com (outbound-smtp34.blacknight.com [46.22.139.253]) by imf21.hostedemail.com (Postfix) with ESMTP id 69F94E0011D9 for ; Wed, 24 Feb 2021 10:26:02 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp34.blacknight.com (Postfix) with ESMTPS id 29C181E1F for ; Wed, 24 Feb 2021 10:26:04 +0000 (GMT) Received: (qmail 23429 invoked from network); 24 Feb 2021 10:26:04 -0000 Received: from unknown (HELO stampy.112glenside.lan) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPA; 24 Feb 2021 10:26:03 -0000 From: Mel Gorman To: Chuck Lever , Jesper Dangaard Brouer Cc: LKML , Linux-Net , Linux-MM , Linux-NFS , Mel Gorman Subject: [RFC PATCH 0/3] Introduce a bulk order-0 page allocator for sunrpc Date: Wed, 24 Feb 2021 10:26:00 +0000 Message-Id: <20210224102603.19524-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 X-Stat-Signature: gcyaore9smqfprh1rxp4zp6ytifyfxfo X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 69F94E0011D9 Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=outbound-smtp34.blacknight.com; client-ip=46.22.139.253 X-HE-DKIM-Result: none/none X-HE-Tag: 1614162362-444572 Content-Transfer-Encoding: quoted-printable 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: This is a prototype series that introduces a bulk order-0 page allocator with sunrpc being the first user. The implementation is not particularly efficient and the intention is to iron out what the semantics of the API should be. That said, sunrpc was reported to have reduced allocation latency when refilling a pool. As a side-note, while the implementation could be more efficient, it would require fairly deep surgery in numerous places. The lock scope woul= d need to be significantly reduced, particularly as vmstat, per-cpu and the buddy allocator have different locking protocol that overal -- 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). In terms of semantics required by new users, my preference is that a pair of patches be applied -- the first which adds the required semantic to the bulk allocator and the second which adds the new user. Patch 1 of this series is a cleanup to sunrpc, it could be merged separately but is included here for convenience. 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?) This has only been lightly tested on a low-end NFS server. It did not bre= ak but would benefit from an evaluation to see how much, if any, the headlin= e performance changes. The biggest concern is that a light test case showed that there are a *lot* of bulk requests for 1 page which gets delegated t= o the normal allocator. The same criteria should apply to any other users. include/linux/gfp.h | 13 +++++ mm/page_alloc.c | 113 +++++++++++++++++++++++++++++++++++++++++- net/sunrpc/svc_xprt.c | 47 ++++++++++++------ 3 files changed, 157 insertions(+), 16 deletions(-) --=20 2.26.2