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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA9BBC433FE for ; Fri, 8 Oct 2021 08:43:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 85A7561039 for ; Fri, 8 Oct 2021 08:43:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 85A7561039 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 1003C900002; Fri, 8 Oct 2021 04:43:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AF8D6B0072; Fri, 8 Oct 2021 04:43:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE049900002; Fri, 8 Oct 2021 04:43:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id DE5FD6B0071 for ; Fri, 8 Oct 2021 04:43:29 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A926318037D3A for ; Fri, 8 Oct 2021 08:43:29 +0000 (UTC) X-FDA: 78672631338.01.9A3BC3B Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf21.hostedemail.com (Postfix) with ESMTP id DDD95D03BFDE for ; Fri, 8 Oct 2021 08:43:28 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="226365399" X-IronPort-AV: E=Sophos;i="5.85,357,1624345200"; d="scan'208";a="226365399" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2021 01:43:27 -0700 X-IronPort-AV: E=Sophos;i="5.85,357,1624345200"; d="scan'208";a="489376744" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.159.119]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2021 01:43:24 -0700 From: "Huang, Ying" To: Mel Gorman Cc: Andrew Morton , Michal Hocko , Rik van Riel , Peter Zijlstra , Dave Hansen , Yang Shi , Zi Yan , Wei Xu , osalvador , Shakeel Butt , , Subject: Re: [PATCH -V9 0/6] NUMA balancing: optimize memory placement for memory tiering system References: <20211008083938.1702663-1-ying.huang@intel.com> Date: Fri, 08 Oct 2021 16:43:22 +0800 In-Reply-To: <20211008083938.1702663-1-ying.huang@intel.com> (Huang Ying's message of "Fri, 8 Oct 2021 16:39:32 +0800") Message-ID: <87ee8vrjo5.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DDD95D03BFDE X-Stat-Signature: b3tnj4te5ag6ar5jrcjkz6eej7q68rrc Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf21.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=ying.huang@intel.com X-HE-Tag: 1633682608-515781 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: Hi, Mel, Huang Ying writes: > The changes since the last post are as follows, > > - Rebased on v5.15-rc4 > > - Make "add promotion counter" the first patch per Yang's comments > > -- > > 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 69263986.8 1830.2 > Patch 2 135691921.4 385.6 11315.9 > Patch 3 133239016.8 384.7 11065.2 > Patch 4 151310868.9 197.6 11397.0 > Patch 5 142311252.8 99.3 9580.8 > Patch 6 149044263.9 65.5 9922.8 > > The whole patchset improves the benchmark score up to 115.2%. The > basic NUMA balancing based optimization solution (patch 2), 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: > > v9: > > - Rebased on v5.15-rc4 > > - Make "add promotion counter" the first patch per Yang's comments In this new version, all dependencies have been merged by the latest upstream kernel. So it is easier to be reviewed than the previous version you have reviewed part of them. Do you have time to take a look at this new series now? Best Regards, Huang, Ying