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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78720C433EF for ; Wed, 8 Jun 2022 09:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235003AbiFHJQs (ORCPT ); Wed, 8 Jun 2022 05:16:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234922AbiFHJOS (ORCPT ); Wed, 8 Jun 2022 05:14:18 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D89736B52 for ; Wed, 8 Jun 2022 01:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654677307; x=1686213307; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=pXuZA38WFCYOEgp/TFGPUQWDuJ5qHdPuNcs8ycMRM54=; b=VWccGwKeVU4FfvlyOydrm/ZilSvE0M+CwpGyTrZtL66R0syzZjVcs8BC hZhFj4eoATCWXO24XBnGCCFhD4L+L/ZygWs6NSLc2Wqb0uVxFEYfijj5W mIchqBclzXOTaRHRMumwGEtUQCvtNYnbBaRs0WTpVzuo0g7AixlHGLOvE E90uqVDQbabRBuaWKLmWshjvvR+bkmf0v5dq3t3E/BhCZriYMMTz4Z+6x HlxCaViwcS1mh9HLxG/Gpb+n3fdJz2gXOKqrzHMjX/suiGe9NaUKqt0Iq vuoQWuWsqlewoe0mt5UvaoGndOsSxl+E6M1M3/IKaP3x1XjmvpBd6IdOW Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="257249466" X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="257249466" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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