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=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,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 85A48C433DB for ; Mon, 22 Mar 2021 09:18:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BB7B6191E for ; Mon, 22 Mar 2021 09:18:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BB7B6191E 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 C79916B007E; Mon, 22 Mar 2021 04:59:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4EF56B0080; Mon, 22 Mar 2021 04:59:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF0216B0082; Mon, 22 Mar 2021 04:59:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by kanga.kvack.org (Postfix) with ESMTP id 8C2316B007E for ; Mon, 22 Mar 2021 04:59:57 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E9AA4180143E4 for ; Mon, 22 Mar 2021 09:18:47 +0000 (UTC) X-FDA: 77946960294.39.AB20494 Received: from outbound-smtp29.blacknight.com (outbound-smtp29.blacknight.com [81.17.249.32]) by imf24.hostedemail.com (Postfix) with ESMTP id 282C9A0000FC for ; Mon, 22 Mar 2021 09:18:47 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp29.blacknight.com (Postfix) with ESMTPS id BA058BEF45 for ; Mon, 22 Mar 2021 09:18:45 +0000 (GMT) Received: (qmail 16087 invoked from network); 22 Mar 2021 09:18:45 -0000 Received: from unknown (HELO stampy.112glenside.lan) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPA; 22 Mar 2021 09:18:45 -0000 From: Mel Gorman To: Andrew Morton Cc: Vlastimil Babka , Chuck Lever , Jesper Dangaard Brouer , Christoph Hellwig , Alexander Duyck , Matthew Wilcox , LKML , Linux-Net , Linux-MM , Linux-NFS , Mel Gorman Subject: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator Date: Mon, 22 Mar 2021 09:18:42 +0000 Message-Id: <20210322091845.16437-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 X-Stat-Signature: 4x5f1ge4744z3ktqnipxbqf9gj4gdj8t X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 282C9A0000FC Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=outbound-smtp29.blacknight.com; client-ip=81.17.249.32 X-HE-DKIM-Result: none/none X-HE-Tag: 1616404727-692877 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 series is based on top of Matthew Wilcox's series "Rationalise __alloc_pages wrapper" and does not apply to 5.12-rc2. If you want to test and are not using Andrew's tree as a baseline, I suggest using the following git tree git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git mm-bulk-rebas= e-v5r9 The users of the API have been dropped in this version as the callers need to check whether they prefer an array or list interface (whether preference is based on convenience or performance). Changelog since v4 o Drop users of the API o Remove free_pages_bulk interface, no users o Add array interface o Allocate single page if watermark checks on local zones fail Changelog since v3 o Rebase on top of Matthew's series consolidating the alloc_pages API o Rename alloced to allocated o Split out preparation patch for prepare_alloc_pages o Defensive check for bulk allocation or <=3D 0 pages o Call single page allocation path only if no pages were allocated o Minor cosmetic cleanups o Reorder patch dependencies by subsystem. As this is a cross-subsystem series, the mm patches have to be merged before the sunrpc and net users. Changelog since v2 o Prep new pages with IRQs enabled o Minor documentation update 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 the intent that sunrpc and the network page pool become 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. Despite that, this is a performance-related enhancement for users that require multiple pages for an operation without multiple round-trips to the page allocator. Quoting the last patch for the prototype high-speed networking use-case. 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). Both potential users in this series are corner cases (NFS and high-speed networks) so it is unlikely that most users will see any benefit in the short term. Other potential other users are batch allocations for page cache readahead, fault around and SLUB allocations when high-order pages are unavailable. It's unknown how much benefit would be seen by convertin= g multiple page allocation calls to a single batch or what difference it ma= y make to headline performance. It's a chicken and egg problem given that the potential benefit cannot be investigated without an implementation to test against. Light testing passed, I'm relying on Chuck and Jesper to test their implementations, choose whether to use lists or arrays and document performance gains/losses in the changelogs. Patch 1 renames a variable name that is particularly unpopular Patch 2 adds a bulk page allocator Patch 3 adds an array-based version of the bulk allocator include/linux/gfp.h | 18 +++++ mm/page_alloc.c | 171 ++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 185 insertions(+), 4 deletions(-) --=20 2.26.2