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 B943CECAAD8 for ; Thu, 1 Sep 2022 07:01:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F94A6B0072; Thu, 1 Sep 2022 03:01:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A8036B0073; Thu, 1 Sep 2022 03:01:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 470806B0074; Thu, 1 Sep 2022 03:01:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 38C9D6B0072 for ; Thu, 1 Sep 2022 03:01:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1079A1A0F42 for ; Thu, 1 Sep 2022 07:01:51 +0000 (UTC) X-FDA: 79862621622.08.3385960 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf07.hostedemail.com (Postfix) with ESMTP id 5CCA74004A for ; Thu, 1 Sep 2022 07:01:49 +0000 (UTC) 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="359594681" X-IronPort-AV: E=Sophos;i="5.93,280,1654585200"; d="scan'208";a="359594681" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662015710; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mTWh8YXhmsW2tW81cRAgAf72o4cgeBwx43N/uJJZqHw=; b=aiVlE6qsjodJUey1gwUou5/Onyrp8WuowC4gSZt/8l9vqd5G7lRckdz9rhqrX7y7LAceJq g4FTapteFJR7YB5sP+hR28DqFkdkS9Xa8ejGX2yoY94UhDNp+50DCPD5oe8vEnLhbanXaf jbGA0NzO4v20dKTJaNx/BGVPvulrbKI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=UVBgClmI; spf=pass (imf07.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662015710; a=rsa-sha256; cv=none; b=O50X6GSfFYEsQD8NgQhX2s577FekFwFF8dAWOiKrCJedByaWMVMH12wl/2GWA1SIC+Ugg8 KVsZu1PECxZf1HkRz8l6F5hLm79BYXQ7b+lPAbSFDG9Uvi9oC2++2KoThqXTaEkMGe08vQ YAf0LHpl8k8uXQl2DCp+8vM3YBFtarw= X-Rspamd-Queue-Id: 5CCA74004A Authentication-Results: imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=UVBgClmI; spf=pass (imf07.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Stat-Signature: a4cprwj5kp91fi1chhwo3xdixqyniyoe X-HE-Tag: 1662015709-572655 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: "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]