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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98C7EC433EF for ; Thu, 23 Dec 2021 01:21:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BCD36B0072; Wed, 22 Dec 2021 20:21:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 144F46B0073; Wed, 22 Dec 2021 20:21:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F25E66B0074; Wed, 22 Dec 2021 20:21:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id DD21A6B0072 for ; Wed, 22 Dec 2021 20:21:11 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 996BE8249980 for ; Thu, 23 Dec 2021 01:21:11 +0000 (UTC) X-FDA: 78947305542.11.A1DC2ED Received: from out30-42.freemail.mail.aliyun.com (out30-42.freemail.mail.aliyun.com [115.124.30.42]) by imf07.hostedemail.com (Postfix) with ESMTP id 6011C40040 for ; Thu, 23 Dec 2021 01:21:07 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R491e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0V.TJOwV_1640222460; Received: from 30.21.164.23(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0V.TJOwV_1640222460) by smtp.aliyun-inc.com(127.0.0.1); Thu, 23 Dec 2021 09:21:01 +0800 Message-ID: <90c5f31f-9e0a-df6d-8639-8a46ee02f9fa@linux.alibaba.com> Date: Thu, 23 Dec 2021 09:21:45 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v2 0/2] Add a new scheme to support demotion on tiered memory system To: "Huang, Ying" Cc: sj@kernel.org, akpm@linux-foundation.org, dave.hansen@linux.intel.com, ziy@nvidia.com, shy828301@gmail.com, zhongjiang-ali@linux.alibaba.com, xlpang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <87a6gsceo6.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Baolin Wang In-Reply-To: <87a6gsceo6.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf07.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.42 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6011C40040 X-Stat-Signature: w3h78gwx3i8gsfu93u3gikh3hhumn7i6 X-HE-Tag: 1640222467-413276 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: On 12/23/2021 9:07 AM, Huang, Ying wrote: > Baolin Wang writes: > >> Hi, >> >> Now on tiered memory system with different memory types, the reclaim path in >> shrink_page_list() already support demoting pages to slow memory node instead >> of discarding the pages. However, at that time the fast memory node memory >> wartermark is already tense, which will increase the memory allocation latency >> during page demotion. So a new method from user space demoting cold pages >> proactively will be more helpful. >> >> We can rely on the DAMON in user space to help to monitor the cold memory on >> fast memory node, and demote the cold pages to slow memory node proactively to >> keep the fast memory node in a healthy state. >> >> This patch set introduces a new scheme named DAMOS_DEMOTE to support this feature, >> and works well from my testing. Any comments are welcome. Thanks. > > As a performance optimization patch, it's better to provide some test > results. Actually this is a functional patch, which adds a new scheme for DAMON. And I think it is too early to measure the performance for the real workload, and more work need to do for DAMON used on tiered memory system (like supporting promotion scheme later). > Another question is why we shouldn't do this in user space? With DAMON, > it's possible to export cold memory regions information to the user > space, then we can use move_pages() to migrate them from DRAM to PMEM. > What's the problem of that? IMO this is the purpose of introducing scheme for DAMON, and you can check more in the Documentation/admin-guide/mm/damon/usage.rst. " Schemes ------- For usual DAMON-based data access aware memory management optimizations, users would simply want the system to apply a memory management action to a memory region of a specific access pattern. DAMON receives such formalized operation schemes from the user and applies those to the target processes. "