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 EA097C433F5 for ; Thu, 23 Dec 2021 03:22:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A6C86B0072; Wed, 22 Dec 2021 22:22:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 32F0F6B0073; Wed, 22 Dec 2021 22:22:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CEC06B0074; Wed, 22 Dec 2021 22:22:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 08F676B0072 for ; Wed, 22 Dec 2021 22:22:43 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B735C180E1E2F for ; Thu, 23 Dec 2021 03:22:42 +0000 (UTC) X-FDA: 78947611764.04.D51659E Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf03.hostedemail.com (Postfix) with ESMTP id 7B2E220015 for ; Thu, 23 Dec 2021 03:22:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1640229761; x=1671765761; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=nVLDDg8On+ICFAWhrHSjhLFb+A4To9duy6snog5e8I4=; b=j61WMmkZZdihioIda4ytkwVPrqEUCp82yoU8N0mOK1znKnAndrPNRoOK nMDbeVWEfmo+xfcmtf+py0BmPSSvlDSqX9xqAFBAhmv1/tu+DPed5IZzV Pw/5UGIOqAsecnT8jqg7qOtK5LRlY3GRe/83hYbF5whgtZcrfsN540I7l B2wLPFSeJEU42Byp78aPFuUGWO5K7f58qr/WMWeB/IuXPPhVHqdKD/v8I nyD5x+MfevUm/B1waOZXmFNhACRoShPSS3XYhZKLXVedRKZooTpil+Azx m2G9ZpNT9cpSAfGRdc1zOuQhX8SA4EzGqGOEzAQqK/yrqIvwZgjFnXTQL Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10206"; a="240698901" X-IronPort-AV: E=Sophos;i="5.88,228,1635231600"; d="scan'208";a="240698901" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2021 19:22:40 -0800 X-IronPort-AV: E=Sophos;i="5.88,228,1635231600"; d="scan'208";a="521926203" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.11]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2021 19:22:37 -0800 From: "Huang, Ying" To: Baolin Wang , Cc: , , , , , , , Subject: Re: [PATCH v2 0/2] Add a new scheme to support demotion on tiered memory system References: <87a6gsceo6.fsf@yhuang6-desk2.ccr.corp.intel.com> <90c5f31f-9e0a-df6d-8639-8a46ee02f9fa@linux.alibaba.com> Date: Thu, 23 Dec 2021 11:22:35 +0800 In-Reply-To: <90c5f31f-9e0a-df6d-8639-8a46ee02f9fa@linux.alibaba.com> (Baolin Wang's message of "Thu, 23 Dec 2021 09:21:45 +0800") Message-ID: <875yrgc8ec.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-Queue-Id: 7B2E220015 X-Stat-Signature: syp61rh99s8oy3rqedsusrachqi6t3cu Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=j61WMmkZ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf03.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=ying.huang@intel.com X-Rspamd-Server: rspam11 X-HE-Tag: 1640229761-728438 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: Baolin Wang writes: > 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). I don't think you provide any new functionality except the performance influence. And I think proactive demotion itself can show some performance benefit already. Just like we can find the performance benefit in the proactive reclaim patchset as below. https://lore.kernel.org/lkml/20211019150731.16699-1-sj@kernel.org/ >> 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. > " For proactive reclaim, we haven't a user space ABI to reclaim a page of a process from memory to disk. So it appears necessary to add a kernel module to do that. But for proactive demotion, we already have a user space ABI (move_pages()) to demote a page of a process from DRAM to PMEM. What prevents you to do all these in the user space? And, I found there are MADV_XXX schemes too. Where the user space ABIs are available already. TBH, I don't know why we need these given there are already user space ABIs. Maybe this is a question for SeongJae too. Best Regards, Huang, Ying