Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3367406pxb; Mon, 1 Mar 2021 08:17:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJxJAPJy9gdLXY96pIUrhJLnThWlZhNZJedrzV0nZHAHJoNwxlBfaoMvqHnA5oZkXX7PCcx6 X-Received: by 2002:a17:906:938f:: with SMTP id l15mr15043885ejx.15.1614615445646; Mon, 01 Mar 2021 08:17:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614615445; cv=none; d=google.com; s=arc-20160816; b=DYojzWgvVBqs+XYzdRvHmPfCKw8qlfj37OjGCaSMaf3YRwMSaOJOia9p7cU3ga54Vh tGQa+JdL8aECcnadkRiIdkDB4lEmZ337GW2/v6FonE/+7b0pkc9ocllLvkNwtnLd9NDn I0nldBKrF3wCP23Bsw1cs0xobB7KfeOr8FfFe1evsxJupgZ3rCt1wReDuyhbUBgwH1Kx FS5BiHse873YmkFhrzVEwvN3EtDKNqlhWpVsAyweVN0a+1UTjp34hvSYenpRti/9krbM EW5kYVT0B3SQYB29UBivrimzVDDcTPU2NeQbLNAkHmtE6OtuN8pOXQx9f071qlqxVajE I5GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=8gFyOTyMNOGEKl/V6YPB5hkpGBM6TQI9whw3ZOz/NeU=; b=LpbCo1aqNugnUbhMHqpFoPprGhXR917wwHoDgFsqJsHxFmmvpWrwW6RYyAid/awY7d NorsX0dF/ZdQXxvE9Oz3saakGRnn3Q44By+RO9by0gQs9QxsbwLbFiCMdhuXUbVu1h/5 j7vHvol3eqZH1JsFc5w1Q7fnsaQ7Gl6i2dLquBP48ThjFRzydtrhihYBOGEl6aI9Qouv uw/1NVCr1bTJHHL/8YH38n/dUi5gfPwRSJzQ3240VzoThfQSOgsy0CeQAuQbvwYcUH3U 1xhubPF4E5Z1g9EbnSbKBRqOlit1og9TjpbSVqZ6O0wWrBZH1gyWr6Tfk86g9e4XmSar zZeQ== 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 co27si10268946edb.376.2021.03.01.08.16.47; Mon, 01 Mar 2021 08:17:25 -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 S237639AbhCAQPB (ORCPT + 99 others); Mon, 1 Mar 2021 11:15:01 -0500 Received: from outbound-smtp55.blacknight.com ([46.22.136.239]:36779 "EHLO outbound-smtp55.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237665AbhCAQNL (ORCPT ); Mon, 1 Mar 2021 11:13:11 -0500 Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp55.blacknight.com (Postfix) with ESMTPS id 6A506FA91A for ; Mon, 1 Mar 2021 16:12:01 +0000 (GMT) Received: (qmail 30423 invoked from network); 1 Mar 2021 16:12:01 -0000 Received: from unknown (HELO stampy.112glenside.lan) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPA; 1 Mar 2021 16:12:01 -0000 From: Mel Gorman To: Andrew Morton Cc: Chuck Lever , Jesper Dangaard Brouer , 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: Mon, 1 Mar 2021 16:11:55 +0000 Message-Id: <20210301161200.18852-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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. 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(-) -- 2.26.2