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 4E33EC433EF for ; Wed, 8 Jun 2022 08:35:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D44B16B00A7; Wed, 8 Jun 2022 04:35:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF3C96B00A8; Wed, 8 Jun 2022 04:35:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBBB36B00A9; Wed, 8 Jun 2022 04:35:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id ADAA56B00A7 for ; Wed, 8 Jun 2022 04:35:40 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 7D875120C6D for ; Wed, 8 Jun 2022 08:35:40 +0000 (UTC) X-FDA: 79554410040.02.44EF049 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf02.hostedemail.com (Postfix) with ESMTP id B394F8003E for ; Wed, 8 Jun 2022 08:35:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654677339; x=1686213339; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=pXuZA38WFCYOEgp/TFGPUQWDuJ5qHdPuNcs8ycMRM54=; b=dKmTMzeiAeeLUh9OUTuqXuNNrvX9chcJvcBk6+qg1/bEZvJplj12wuSw ORRQNIaNR1OxCkhRsUxrYrS5vWz1s3UllvXS6EBlCpRKgFQotunkA74j9 SgvFi+F14lsUvOyOfvtSYJQWWk+NtD9sbf5ZF79waI9Xczx1NvbQSCXRs PNtGpQUu6V1stQ7kST2XfEiJwn3t9do5UP3N9iGxYJ2PjoppsyLfD/x2V D0RFBNs1V/K/5k3xeNduxEk1/9nvoIkWMZzZVlNu0NgR8PUNlcA5RsxFU cq8sBHsz4ZjzHOG4GnEk5IjjR/z6VxhRd4z4v7TdcZGzJak6XxpzAAnHQ w==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="302173564" X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="302173564" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 01:35:06 -0700 X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="636677405" Received: from xding11-mobl.ccr.corp.intel.com ([10.254.214.239]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 01:35:02 -0700 Message-ID: <65b77f7f89361144602dce208ba4cb32387cf330.camel@intel.com> Subject: Re: [PATCH v5 6/9] mm/demotion: Add support for removing node from demotion memory tiers From: Ying Huang To: Aneesh Kumar K V , linux-mm@kvack.org, akpm@linux-foundation.org Cc: Wei Xu , Greg Thelen , Yang Shi , Davidlohr Bueso , Tim C Chen , Brice Goglin , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Feng Tang , Jagdish Gediya , Baolin Wang , David Rientjes Date: Wed, 08 Jun 2022 16:34:59 +0800 In-Reply-To: References: <20220603134237.131362-1-aneesh.kumar@linux.ibm.com> <20220603134237.131362-7-aneesh.kumar@linux.ibm.com> <81956d2e-0bfe-78ba-5ad0-f6c388c2190e@linux.ibm.com> <06d04b6588b43ca010ec78ce0dee8127193f5562.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Stat-Signature: ggee39ppnoop99azsjuhiowm8e9hph61 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dKmTMzei; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf02.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B394F8003E X-HE-Tag: 1654677339-167077 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 Wed, 2022-06-08 at 13:59 +0530, Aneesh Kumar K V wrote: > On 6/8/22 1:53 PM, Ying Huang wrote: > > On Wed, 2022-06-08 at 13:50 +0530, Aneesh Kumar K V wrote: > > > On 6/8/22 12:29 PM, Ying Huang wrote: > > > > On Fri, 2022-06-03 at 19:12 +0530, Aneesh Kumar K.V wrote: > > > > > This patch adds the special string "none" as a supported memtier value > > > > > that we can use to remove a specific node from being using as demotion target. > > > > > > > > > > For ex: > > > > > :/sys/devices/system/node/node1# cat memtier > > > > > 1 > > > > > :/sys/devices/system/node/node1# cat ../../memtier/memtier1/nodelist > > > > > 1-3 > > > > > :/sys/devices/system/node/node1# echo none > memtier > > > > > :/sys/devices/system/node/node1# > > > > > :/sys/devices/system/node/node1# cat memtier > > > > > :/sys/devices/system/node/node1# cat ../../memtier/memtier1/nodelist > > > > > 2-3 > > > > > :/sys/devices/system/node/node1# > > > > > > > > Do you have a practical use case for this? What kind of memory node > > > > needs to be removed from memory tiers demotion/promotion? > > > > > > > > > > This came up in our internal discussion. It was mentioned that there is > > > a need to skip some slow memory nodes from participating in demotion. > > > > Again, can you provide a practical use case? Why we shouldn't demote > > cold pages to these slow memory nodes? How do we use these slow memory > > node? These slow memory node is slower than disk? > > > > This was discussed in the context of memory borrowed from remote machine > (aka OpenCAPI memory). In such case, we would have a memory only NUMA > node which we want to avoid using for demotion. Thanks for your information. But why shouldn't we use them for demotion? Because it's too slow? Even slower than disks? Or some other reason? Best Regards, Huang, Ying