From patchwork Fri Apr 8 07:12:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Ying" X-Patchwork-Id: 12806179 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA87FC433EF for ; Fri, 8 Apr 2022 07:12:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E60246B0071; Fri, 8 Apr 2022 03:12:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E10A96B0072; Fri, 8 Apr 2022 03:12:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD7BC6B0074; Fri, 8 Apr 2022 03:12:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id BAC196B0071 for ; Fri, 8 Apr 2022 03:12:48 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 681C9AF4EA for ; Fri, 8 Apr 2022 07:12:48 +0000 (UTC) X-FDA: 79332844416.28.753127A Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf24.hostedemail.com (Postfix) with ESMTP id A21C9180005 for ; Fri, 8 Apr 2022 07:12:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649401967; x=1680937967; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=p9Vyinh/bxnpuA3ME5EXESNvBi6g7SL/nHb8H8N/Zz8=; b=IoVcpp1b25wu7Dr1eZxdOeDArJdhnDi5YSV2MvLjXdLpdi9AHt2uJnBm eWiS/0ftshTIa96wq33xRquudPchBDSMxnGkwCLuwCtAqXw8x/Nq8hMZf /1955/Q9KXq+KDcppMJLzyWl3rgBQvPlp+pmI5hqYhuDDU65ILAePRr/L HtGQkxCmrvY4mPkkstdGSa103qK/gGm7FPq97P80Y1OaRC2TQJOzWaqMD JAgspFIughIQZAQL/cK+lDRGucpt7NKlxzo1nA2QoiMm62hZwwgdDUoMG HpUcbXmw6nw4NcCx6r2KoVZCx8SNt6dof0r2+Tc1syXtaawO9Iu3Ki58P w==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="259129771" X-IronPort-AV: E=Sophos;i="5.90,244,1643702400"; d="scan'208";a="259129771" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 00:12:46 -0700 X-IronPort-AV: E=Sophos;i="5.90,244,1643702400"; d="scan'208";a="550403934" Received: from fangyaxu-mobl.ccr.corp.intel.com (HELO yhuang6-mobl1.ccr.corp.intel.com) ([10.254.214.217]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 00:12:42 -0700 From: Huang Ying To: Peter Zijlstra , Mel Gorman , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , Michal Hocko , Rik van Riel , Dave Hansen , Yang Shi , Zi Yan , Wei Xu , osalvador , Shakeel Butt , Zhong Jiang Subject: [PATCH 0/3] memory tiering: hot page selection Date: Fri, 8 Apr 2022 15:12:19 +0800 Message-Id: <20220408071222.219689-1-ying.huang@intel.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A21C9180005 X-Stat-Signature: 9i8mpfqjxjonbhyryum93u1w5dtx1rae Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IoVcpp1b; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf24.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-HE-Tag: 1649401967-806272 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: To optimize page placement in a memory tiering system with NUMA balancing, the hot pages in the slow memory node need to be identified. Essentially, the original NUMA balancing implementation selects and promote the mostly recently accessed (MRU) pages. But the recently accessed pages may be cold. So in this patchset, we implement a new hot page identification algorithm based on the latency between NUMA balancing page table scanning and hint page fault. And the hot page promotion can incur some overhead in the system. To control the overhead a simple promotion rate limit mechanism is implemented. The hot threshold used to identify the hot pages is workload dependent usually. So we also implemented a hot threshold automatic adjustment algorithm. The basic idea is to increase/decrease the hot threshold to make the number of pages that pass the hot threshold (promote candidate) near the rate limit. We used the pmbench memory accessing benchmark tested the patchset on a 2-socket server system with DRAM and PMEM installed. The test results are as follows, pmbench score promote rate (accesses/s) MB/s ------------- ------------ base 146887704.1 725.6 hot selection 165695601.2 544.0 rate limit 162814569.8 165.2 auto adjustment 170495294.0 136.9 From the results above, With hot page selection patch [1/3], the pmbench score increases about 12.8%, and promote rate (overhead) decreases about 25.0%, compared with base kernel. With rate limit patch [2/3], pmbench score decreases about 1.7%, and promote rate decreases about 69.6%, compared with hot page selection patch. With threshold auto adjustment patch [3/3], pmbench score increases about 4.7%, and promote rate decrease about 17.1%, compared with rate limit patch. Best Regards, Huang, Ying