Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp380687rwe; Thu, 1 Sep 2022 00:37:23 -0700 (PDT) X-Google-Smtp-Source: AA6agR5Lutf/eDWdQunJdLSyELiAyrnALZK9y16phJoBxprOIDJVM5eWQ+35+9AnzthdjJR5D4JE X-Received: by 2002:a17:902:e98c:b0:174:4f67:890a with SMTP id f12-20020a170902e98c00b001744f67890amr26229142plb.44.1662017842895; Thu, 01 Sep 2022 00:37:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662017842; cv=none; d=google.com; s=arc-20160816; b=W9H6I2R5NauOoqPMJboaK72YpHKwWgI9/5JqyUHtsheCZyrRcXXSt7mP93r8QJYGXA E6e6PHbWWmbxnQh9wdqsT/eSoJrN28YqSRaGjPTmkoqf6pizpnw6edVFstvTJ4eM8g2s jwb9bpNOmFFG7kafEyN8FvAtgkFwf7adERQryAi/dzVMYFww39Kwke8cAzxpHTzaoQvO O6sKX8YdGSXPVUzC4JUxf+E9tMKLoybJNT6ZqBETUTEFG6WV/unRavi9Ukjc8VvLzCOf g47os+AO6Bw9vxd7+ufgugzfaspWURYBn5SCALMiJBBJt55EY3BLaivH8L44wB7Vsl/y l19g== 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:message-id:in-reply-to:date:references:subject:cc:to :from:dkim-signature; bh=mTWh8YXhmsW2tW81cRAgAf72o4cgeBwx43N/uJJZqHw=; b=XSGKf1C63+H9tz/+R/szl/MUTGhkukLY7yfhKNBfatSk8nTPc+WWs3IIq665roeG4N 352XfGGUPHQpf3kI82vWtFrf1RLbbhz1CqctCcnbrxg4huBcRKtnFVoHBdJTN0jZzYch P0OrI33ffBKAzu3BJPcHD/4HJeuC70C2aSMAZVGUg8QLxBRUxtQnaOBTQtB5tm5+iD/w y9j+YONeIsmy3fQyPeORj5pUmaPheE/GFK12qlmHJo1ZYAfcQfhzk/J7l+ibrbi+OJvS gpn59UR/fGwk/pjLKO3cVvUaHnITD0SrY5QB8w76dsyZEvJe4WqUtOJN6nJ6i4HOEl/l jlPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UVBgClmI; 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 t21-20020a170902b21500b00172c9d17507si16177308plr.39.2022.09.01.00.37.10; Thu, 01 Sep 2022 00:37:22 -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=UVBgClmI; 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 S233496AbiIAHC7 (ORCPT + 99 others); Thu, 1 Sep 2022 03:02:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233354AbiIAHCf (ORCPT ); Thu, 1 Sep 2022 03:02:35 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 661A8124864 for ; Thu, 1 Sep 2022 00:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662015709; x=1693551709; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=V5eFPntE7kEE/MubUOdAVDILHNkJ4zNIH5bzumuL+3k=; b=UVBgClmIGJ8XlmlPXOZsEWkSP8h7R+UhfHcHtDbmeyQhDrDo22EAb1qp PjefgHSnw/xKMN8wSmvDETORsD4ES8jadqkOfxMJJCvtO2pauBfkq/MZE IVmTmVBQ6y5OPru9EWviVUu13s5jkAwAUiq8kL8hCS1X39ngEKA2B8D1h WP7rzzl9ORBPCq4W/5Uv86zKUoHp+KTQAsW2elBbwW0DXykMisFhz3CvC 3A01NwZcyepP3DyhVZ/LvUIreZE8rRZR7ljCZWZgSX8r2pQfDpJS+nbz9 3x7w0gG/LAksPqkx0227yy9g/4TSahH4PvTEH3JsUPbcuyt2ZJxBQWvbz A==; X-IronPort-AV: E=McAfee;i="6500,9779,10456"; a="296418944" X-IronPort-AV: E=Sophos;i="5.93,280,1654585200"; d="scan'208";a="296418944" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 00:01:48 -0700 X-IronPort-AV: E=Sophos;i="5.93,280,1654585200"; d="scan'208";a="642205433" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 00:01:41 -0700 From: "Huang, Ying" To: "Aneesh Kumar K.V" , Wei Xu , Johannes Weiner Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , jvgediya.oss@gmail.com, Bharata B Rao Subject: Re: [PATCH v3 updated] mm/demotion: Expose memory tier details via sysfs References: <20220830081736.119281-1-aneesh.kumar@linux.ibm.com> Date: Thu, 01 Sep 2022 15:01:39 +0800 In-Reply-To: <20220830081736.119281-1-aneesh.kumar@linux.ibm.com> (Aneesh Kumar K. V.'s message of "Tue, 30 Aug 2022 13:47:36 +0530") Message-ID: <87tu5rzigc.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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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 "Aneesh Kumar K.V" writes: > This patch adds /sys/devices/virtual/memory_tiering/ where all memory tier > related details can be found. All allocated memory tiers will be listed > there as /sys/devices/virtual/memory_tiering/memory_tierN/ > > The nodes which are part of a specific memory tier can be listed via > /sys/devices/virtual/memory_tiering/memory_tierN/nodes I think "memory_tier" is a better subsystem/bus name than memory_tiering. Because we have a set of memory_tierN devices inside. "memory_tier" sounds more natural. I know this is subjective, just my preference. > > A directory hierarchy looks like > :/sys/devices/virtual/memory_tiering$ tree memory_tier4/ > memory_tier4/ > =E2=94=9C=E2=94=80=E2=94=80 nodes > =E2=94=9C=E2=94=80=E2=94=80 subsystem -> ../../../../bus/memory_tiering > =E2=94=94=E2=94=80=E2=94=80 uevent > > All toptier nodes are listed via > /sys/devices/virtual/memory_tiering/toptier_nodes > > :/sys/devices/virtual/memory_tiering$ cat toptier_nodes > 0,2 > :/sys/devices/virtual/memory_tiering$ cat memory_tier4/nodes > 0,2 I don't think that it is a good idea to show toptier information in user space interface. Because it is just a in kernel implementation details. Now, we only promote pages from !toptier to toptier. But there may be multiple memory tiers in toptier and !toptier, we may change the implementation in the future. For example, we may promote pages from DRAM to HBM in the future. Do we need a way to show the default memory tier in sysfs? That is, the memory tier that the DRAM nodes belong to. Best Regards, Huang, Ying > Signed-off-by: Aneesh Kumar K.V > --- > > Changes from v2: > * update macro to static inline > * Fix build error with CONFIG_MIGRATION disabled > * drop abstract_distance > * update commit message > > [snip]