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 4605AECAAD2 for ; Thu, 1 Sep 2022 07:03:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232699AbiIAHC7 (ORCPT ); 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 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]