From patchwork Fri Jun 18 03:44:38 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 12330047 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,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 11588C49EA2 for ; Fri, 18 Jun 2021 03:44:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A36C561245 for ; Fri, 18 Jun 2021 03:44:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A36C561245 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1B9586B0070; Thu, 17 Jun 2021 23:44:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16A8B6B0071; Thu, 17 Jun 2021 23:44:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00AC16B0072; Thu, 17 Jun 2021 23:44:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id BEE7A6B0070 for ; Thu, 17 Jun 2021 23:44:56 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 63FFCB799 for ; Fri, 18 Jun 2021 03:44:56 +0000 (UTC) X-FDA: 78265453392.05.A833E0F Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf12.hostedemail.com (Postfix) with ESMTP id B248354C for ; Fri, 18 Jun 2021 03:44:54 +0000 (UTC) IronPort-SDR: +p0eAHmsoKAiWh+Jjj7U6DsEaHZ2iedOUa5JGnjJm/NPmFPPnzFNDzvsgNlGz2/q3bIqH4IZQ+ e3MwiVzoBuDw== X-IronPort-AV: E=McAfee;i="6200,9189,10018"; a="203467002" X-IronPort-AV: E=Sophos;i="5.83,281,1616482800"; d="scan'208";a="203467002" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2021 20:44:49 -0700 IronPort-SDR: 0N2poWjcGlgPP5SEiYJ9BPGJLhBrjBzjdcZAin1DppoX2RhJI+IkZgJFN4rXFpK/rQm+zYYswQ uhUDVVI5uv1w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,281,1616482800"; d="scan'208";a="485539795" Received: from shbuild999.sh.intel.com ([10.239.147.94]) by orsmga001.jf.intel.com with ESMTP; 17 Jun 2021 20:44:44 -0700 From: Feng Tang To: linux-mm@kvack.org, Andrew Morton , Michal Hocko , David Rientjes , Dave Hansen , Ben Widawsky Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Andrea Arcangeli , Mel Gorman , Mike Kravetz , Randy Dunlap , Vlastimil Babka , Andi Kleen , Dan Williams , ying.huang@intel.com, Feng Tang Subject: [PATCH v5 -mm 0/6] Introduced multi-preference mempolicy Date: Fri, 18 Jun 2021 11:44:38 +0800 Message-Id: <1623987884-43576-1-git-send-email-feng.tang@intel.com> X-Mailer: git-send-email 2.7.4 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B248354C X-Stat-Signature: xiz5cgmmesi7zabbc4f7pmcfwnbsdex4 Authentication-Results: imf12.hostedemail.com; dkim=none; spf=none (imf12.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=feng.tang@intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-HE-Tag: 1623987894-761031 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 patch series introduces the concept of the MPOL_PREFERRED_MANY mempolicy. This mempolicy mode can be used with either the set_mempolicy(2) or mbind(2) interfaces. Like the MPOL_PREFERRED interface, it allows an application to set a preference for nodes which will fulfil memory allocation requests. Unlike the MPOL_PREFERRED mode, it takes a set of nodes. Like the MPOL_BIND interface, it works over a set of nodes. Unlike MPOL_BIND, it will not cause a SIGSEGV or invoke the OOM killer if those preferred nodes are not available. Along with these patches are patches for libnuma, numactl, numademo, and memhog. They still need some polish, but can be found here: https://gitlab.com/bwidawsk/numactl/-/tree/prefer-many It allows new usage: `numactl -P 0,3,4` The goal of the new mode is to enable some use-cases when using tiered memory usage models which I've lovingly named. 1a. The Hare - The interconnect is fast enough to meet bandwidth and latency requirements allowing preference to be given to all nodes with "fast" memory. 1b. The Indiscriminate Hare - An application knows it wants fast memory (or perhaps slow memory), but doesn't care which node it runs on. The application can prefer a set of nodes and then xpu bind to the local node (cpu, accelerator, etc). This reverses the nodes are chosen today where the kernel attempts to use local memory to the CPU whenever possible. This will attempt to use the local accelerator to the memory. 2. The Tortoise - The administrator (or the application itself) is aware it only needs slow memory, and so can prefer that. Much of this is almost achievable with the bind interface, but the bind interface suffers from an inability to fallback to another set of nodes if binding fails to all nodes in the nodemask. Like MPOL_BIND a nodemask is given. Inherently this removes ordering from the preference. > /* Set first two nodes as preferred in an 8 node system. */ > const unsigned long nodes = 0x3 > set_mempolicy(MPOL_PREFER_MANY, &nodes, 8); > /* Mimic interleave policy, but have fallback *. > const unsigned long nodes = 0xaa > set_mempolicy(MPOL_PREFER_MANY, &nodes, 8); Some internal discussion took place around the interface. There are two alternatives which we have discussed, plus one I stuck in: 1. Ordered list of nodes. Currently it's believed that the added complexity is nod needed for expected usecases. 2. A flag for bind to allow falling back to other nodes. This confuses the notion of binding and is less flexible than the current solution. 3. Create flags or new modes that helps with some ordering. This offers both a friendlier API as well as a solution for more customized usage. It's unknown if it's worth the complexity to support this. Here is sample code for how this might work: > // Prefer specific nodes for some something wacky > set_mempolicy(MPOL_PREFER_MANY, 0x17c, 1024); > > // Default > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_SOCKET, NULL, 0); > // which is the same as > set_mempolicy(MPOL_DEFAULT, NULL, 0); > > // The Hare > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE, NULL, 0); > > // The Tortoise > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE_REV, NULL, 0); > > // Prefer the fast memory of the first two sockets > set_mempolicy(MPOL_PREFER_MANY | MPOL_F_PREFER_ORDER_TYPE, -1, 2); > In v1, Andi Kleen brought up reusing MPOL_PREFERRED as the mode for the API. There wasn't consensus around this, so I've left the existing API as it was. I'm open to more feedback here, but my slight preference is to use a new API as it ensures if people are using it, they are entirely aware of what they're doing and not accidentally misusing the old interface. (In a similar way to how MPOL_LOCAL was introduced). In v1, Michal also brought up renaming this MPOL_PREFERRED_MASK. I'm equally fine with that change, but I hadn't heard much emphatic support for one way or another, so I've left that too. --- Changelog: Since v4: * Rebased on latest -mm tree (v5.13-rc), whose mempolicy code has been refactored much since v4 submission * add a dedicated alloc_page_preferred_many() (Michal Hocko) * refactor and add fix to hugetlb supporting code (Michal Hocko) Since v3: * Rebased against v5.12-rc2 * Drop the v3/0013 patch of creating NO_SLOWPATH gfp_mask bit * Skip direct reclaim for the first allocation try for MPOL_PREFERRED_MANY, which makes its semantics close to existing MPOL_PREFFERRED policy Since v2: * Rebased against v5.11 * Fix a stack overflow related panic, and a kernel warning (Feng) * Some code clearup (Feng) * One RFC patch to speedup mem alloc in some case (Feng) Since v1: * Dropped patch to replace numa_node_id in some places (mhocko) * Dropped all the page allocation patches in favor of new mechanism to use fallbacks. (mhocko) * Dropped the special snowflake preferred node algorithm (bwidawsk) * If the preferred node fails, ALL nodes are rechecked instead of just the non-preferred nodes. Ben Widawsky (3): mm/mempolicy: enable page allocation for MPOL_PREFERRED_MANY for general cases mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY mm/mempolicy: Advertise new MPOL_PREFERRED_MANY Dave Hansen (1): mm/mempolicy: Add MPOL_PREFERRED_MANY for multiple preferred nodes Feng Tang (2): mm/memplicy: add page allocation function for MPOL_PREFERRED_MANY policy mm/mempolicy: unify the create() func for bind/interleave/prefer-many policies .../admin-guide/mm/numa_memory_policy.rst | 16 +++-- include/uapi/linux/mempolicy.h | 1 + mm/hugetlb.c | 27 +++++++- mm/mempolicy.c | 75 +++++++++++++++++----- 4 files changed, 96 insertions(+), 23 deletions(-)