Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp6221040ioo; Thu, 2 Jun 2022 01:26:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFacMaXKhutkBj1BNKcPq/+oVQqMndpqMxlVS1LRuE+8ggLck91xw7Q6HnoCKZPFL6cwSD X-Received: by 2002:a63:86c8:0:b0:3fc:5c70:42a8 with SMTP id x191-20020a6386c8000000b003fc5c7042a8mr3120169pgd.609.1654158372102; Thu, 02 Jun 2022 01:26:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654158372; cv=none; d=google.com; s=arc-20160816; b=OuyrXJjqZZ7jjJSGtaZLyijG5LoPLNb+OhdD75nDVYUes9SE2JJzSHTtN3lmkjlclh fMFtnkUaTNkesdfLBP2AjbaNBfA9Yx6KqgHuNOiuUts+affH+kkkrtaYXS5N+sHlyIym 213NQu0NAJ6RWUs2WXaI6MnYpKyChHTV89lcX8LOVnyjSYUrIVE8UCBAgpjJ6EJg90kw g63Zx72IZctoBpQg/1mFyU/KSsPYpVF4xdqhvtSXg/qMaHg15vTdmminoXNfbJy/42Rk RZ2CzuKbYF9FV54VseRJcE5K2aVolZSZA+TfGMM3BA8VnpqZkCxtv18QSYZZ2n2d5+BI STgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=KBflYaba18Y66ERHn2G2TJqxAs+chhFvElpzQVsaQjY=; b=pPFBksQdYWaVwkXhvJXMU22G9LANHZqvQveAOQr5zjzmSPrPUcNvRMKQuzXESbRt84 9lLgDBCkQRyGR8jpBGu102P4Bm14hG01eezBggOi5JfD1h/4xQlyp32QmeOyZQARKWPD jL8qlY+yc7VThKamu6ATgQCwlT6ukDCfX3rOnL+lZ7sOh7T/QGWFa9O3Z2Km353clN4Y 331eXEuDnrX5W/4DzHaode9vMJH8aLEW13MKHJPlCmSuIKDUpcYgpY2Bj0mU8x20ELn0 4tmb/Hm2VzTKDDBwC9Eg+IHbh+nDNAkss15s4al8B84YIR3j8ap6276guUerVQCJ8Fj+ R2lA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=P5DR1tbG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y71-20020a638a4a000000b003fb210a74absi2177513pgd.488.2022.06.02.01.26.00; Thu, 02 Jun 2022 01:26:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=P5DR1tbG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231486AbiFBGlu (ORCPT + 99 others); Thu, 2 Jun 2022 02:41:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231439AbiFBGlt (ORCPT ); Thu, 2 Jun 2022 02:41:49 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22F522A3A04 for ; Wed, 1 Jun 2022 23:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654152107; x=1685688107; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=hkExu+xypCvEZ2GrPWlhA1VX0WFEoqjTwVjGVoC+Nkk=; b=P5DR1tbGOGWXVWqNjyB5RITAgEzUngeKBfVsVIwpJRAjxUBya+WhvA0I UPnDQXnsIB+w94R3O5wciIox0biEbl8K51NIk9hj48dGbcs/ajZC1Rfpj okAd6YGiYyltQr1UHsoh3QIdlP0x4gPwmnSyrGD4RFVkBq+I43k6ukbz2 Xa2mSw7zGHPTg2tpeG8K0dFDpchs/3ESgEujofsX+UUYEW7xkOU00RSL8 T12SkzA86P2AbZGffXB7DcEucymHzW3wvlD9GlKbBxFXsy/EJYjOWPYLj YqtmqjFDVa2fqdpIl3XuwHYbiI2X133TC8z+miC9OAQ83IIqxHOfqpwIE Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10365"; a="301206430" X-IronPort-AV: E=Sophos;i="5.91,270,1647327600"; d="scan'208";a="301206430" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2022 23:41:46 -0700 X-IronPort-AV: E=Sophos;i="5.91,270,1647327600"; d="scan'208";a="552685962" Received: from yanqingl-mobl1.ccr.corp.intel.com ([10.254.212.10]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2022 23:41:41 -0700 Message-ID: Subject: Re: [RFC PATCH v4 5/7] mm/demotion: Add support to associate rank with memory tier From: Ying Huang To: "Aneesh Kumar K.V" , linux-mm@kvack.org, akpm@linux-foundation.org Cc: 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: Thu, 02 Jun 2022 14:41:39 +0800 In-Reply-To: <20220527122528.129445-6-aneesh.kumar@linux.ibm.com> References: <20220527122528.129445-1-aneesh.kumar@linux.ibm.com> <20220527122528.129445-6-aneesh.kumar@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-05-27 at 17:55 +0530, Aneesh Kumar K.V wrote: > The rank approach allows us to keep memory tier device IDs stable even if there > is a need to change the tier ordering among different memory tiers. e.g. DRAM > nodes with CPUs will always be on memtier1, no matter how many tiers are higher > or lower than these nodes. A new memory tier can be inserted into the tier > hierarchy for a new set of nodes without affecting the node assignment of any > existing memtier, provided that there is enough gap in the rank values for the > new memtier. > > The absolute value of "rank" of a memtier doesn't necessarily carry any meaning. > Its value relative to other memtiers decides the level of this memtier in the tier > hierarchy. > > For now, This patch supports hardcoded rank values which are 100, 200, & 300 for > memory tiers 0,1 & 2 respectively. > > Below is the sysfs interface to read the rank values of memory tier, > /sys/devices/system/memtier/memtierN/rank > > This interface is read only for now, write support can be added when there is > a need of flexibility of more number of memory tiers(> 3) with flexibile ordering > requirement among them, rank can be utilized there as rank decides now memory > tiering ordering and not memory tier device ids. > > Signed-off-by: Aneesh Kumar K.V > --- >  drivers/base/node.c | 5 +- >  drivers/dax/kmem.c | 2 +- >  include/linux/migrate.h | 17 ++-- >  mm/migrate.c | 218 ++++++++++++++++++++++++---------------- >  4 files changed, 144 insertions(+), 98 deletions(-) > > diff --git a/drivers/base/node.c b/drivers/base/node.c > index cf4a58446d8c..892f7c23c94e 100644 > --- a/drivers/base/node.c > +++ b/drivers/base/node.c > @@ -567,8 +567,11 @@ static ssize_t memtier_show(struct device *dev, >   char *buf) >  { >   int node = dev->id; > + int tier_index = node_get_memory_tier_id(node); >   > > > > - return sysfs_emit(buf, "%d\n", node_get_memory_tier(node)); > + if (tier_index != -1) > + return sysfs_emit(buf, "%d\n", tier_index); > + return 0; >  } >   > > > >  static ssize_t memtier_store(struct device *dev, > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c > index 991782aa2448..79953426ddaf 100644 > --- a/drivers/dax/kmem.c > +++ b/drivers/dax/kmem.c > @@ -149,7 +149,7 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax) >   dev_set_drvdata(dev, data); >   > > > >  #ifdef CONFIG_TIERED_MEMORY > - node_set_memory_tier(numa_node, MEMORY_TIER_PMEM); > + node_set_memory_tier_rank(numa_node, MEMORY_RANK_PMEM); I think that we can work with memory tier ID inside kernel? Best Regards, Huang, Ying [snip]