From patchwork Tue Sep 14 01:36:55 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Ying" X-Patchwork-Id: 12491189 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=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=no 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 56B54C433F5 for ; Tue, 14 Sep 2021 01:37:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D5A0F61216 for ; Tue, 14 Sep 2021 01:37:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D5A0F61216 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 29E5F6B0071; Mon, 13 Sep 2021 21:37:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24A7A6B0072; Mon, 13 Sep 2021 21:37:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F6D9900002; Mon, 13 Sep 2021 21:37:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id F37546B0071 for ; Mon, 13 Sep 2021 21:37:20 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 994441812D475 for ; Tue, 14 Sep 2021 01:37:20 +0000 (UTC) X-FDA: 78584466240.10.11DE637 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf02.hostedemail.com (Postfix) with ESMTP id F2A7A7001A08 for ; Tue, 14 Sep 2021 01:37:19 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10106"; a="285534857" X-IronPort-AV: E=Sophos;i="5.85,291,1624345200"; d="scan'208";a="285534857" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2021 18:37:18 -0700 X-IronPort-AV: E=Sophos;i="5.85,291,1624345200"; d="scan'208";a="543575247" Received: from yhuang6-desk2.sh.intel.com ([10.239.159.119]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2021 18:37:14 -0700 From: Huang Ying To: linux-kernel@vger.kernel.org Cc: Huang Ying , Andrew Morton , Michal Hocko , Rik van Riel , Mel Gorman , Peter Zijlstra , Dave Hansen , Yang Shi , Zi Yan , Wei Xu , osalvador , Shakeel Butt , linux-mm@kvack.org Subject: [PATCH -V8 0/6] NUMA balancing: optimize memory placement for memory tiering system Date: Tue, 14 Sep 2021 09:36:55 +0800 Message-Id: <20210914013701.344956-1-ying.huang@intel.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf02.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=ying.huang@intel.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F2A7A7001A08 X-Stat-Signature: bwc1qo75zymrnjr8kbbcf5frai4zsost X-HE-Tag: 1631583439-398667 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: The changes since the last post are as follows, - Rebased on latest upstream kernel (v5.15-rc1) - Make user-specified threshold take effect sooner --- With the advent of various new memory types, some machines will have multiple types of memory, e.g. DRAM and PMEM (persistent memory). The memory subsystem of these machines can be called memory tiering system, because the performance of the different types of memory are different. After commit c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM"), the PMEM could be used as the cost-effective volatile memory in separate NUMA nodes. In a typical memory tiering system, there are CPUs, DRAM and PMEM in each physical NUMA node. The CPUs and the DRAM will be put in one logical node, while the PMEM will be put in another (faked) logical node. To optimize the system overall performance, the hot pages should be placed in DRAM node. To do that, we need to identify the hot pages in the PMEM node and migrate them to DRAM node via NUMA migration. In the original NUMA balancing, there are already a set of existing mechanisms to identify the pages recently accessed by the CPUs in a node and migrate the pages to the node. So we can reuse these mechanisms to build the mechanisms to optimize the page placement in the memory tiering system. This is implemented in this patchset. At the other hand, the cold pages should be placed in PMEM node. So, we also need to identify the cold pages in the DRAM node and migrate them to PMEM node. In commit 26aa2d199d6f ("mm/migrate: demote pages during reclaim"), a mechanism to demote the cold DRAM pages to PMEM node under memory pressure is implemented. Based on that, the cold DRAM pages can be demoted to PMEM node proactively to free some memory space on DRAM node to accommodate the promoted hot PMEM pages. This is implemented in this patchset too. We have tested the solution with the pmbench memory accessing benchmark with the 80:20 read/write ratio and the normal access address distribution on a 2 socket Intel server with Optane DC Persistent Memory Model. The test results of the base kernel and step by step optimizations are as follows, Throughput Promotion DRAM bandwidth access/s MB/s MB/s ----------- ---------- -------------- Base 74238178.0 4291.7 Patch 2 146050652.3 359.4 11248.6 Patch 3 146300787.1 355.2 11237.2 Patch 4 162536383.0 211.7 11890.4 Patch 5 157187775.0 105.9 10412.3 Patch 6 164028415.2 73.3 10810.6 The whole patchset improves the benchmark score up to 119.1%. The basic NUMA balancing based optimization solution (patch 1), the hot page selection algorithm (patch 4), and the threshold automatic adjustment algorithms (patch 6) improves the performance or reduce the overhead (promotion MB/s) greatly. Changelog: v8: - Rebased on latest upstream kernel (v5.15-rc1) - Make user-specified threshold take effect sooner v7: - Rebased on the mmots tree of 2021-07-15. - Some minor fixes. v6: - Rebased on the latest page demotion patchset. (which bases on v5.11) v5: - Rebased on the latest page demotion patchset. (which bases on v5.10) v4: - Rebased on the latest page demotion patchset. (which bases on v5.9-rc6) - Add page promotion counter. v3: - Move the rate limit control as late as possible per Mel Gorman's comments. - Revise the hot page selection implementation to store page scan time in struct page. - Code cleanup. - Rebased on the latest page demotion patchset. v2: - Addressed comments for V1. - Rebased on v5.5. Best Regards, Huang, Ying