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 BB3B1C04A95 for ; Mon, 26 Sep 2022 01:04:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDB538E0029; Sun, 25 Sep 2022 21:04:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8A478E0007; Sun, 25 Sep 2022 21:04:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B516D8E0029; Sun, 25 Sep 2022 21:04:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A5C3B8E0007 for ; Sun, 25 Sep 2022 21:04:32 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8C5751C5C93 for ; Mon, 26 Sep 2022 01:04:32 +0000 (UTC) X-FDA: 79952441184.10.2B0F394 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf07.hostedemail.com (Postfix) with ESMTP id 651DB40004 for ; Mon, 26 Sep 2022 01:04:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664154271; x=1695690271; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=ewrjyWVMkrf0F3lb0gU9athQ8P36/hdOKSpNw/dHgsc=; b=Jj4qB8Vll54HhurWrMaOoJRa9h5OFgWdiOkUqFKC5VhIBVl1kA7MZNif l3N7VmeNRetljoqe5hnHlvQksC493mBc7OfkxLy2sKE4SlFqix9jBCi9v s8XZNgdDANWH1u5WrUobHUa6k8Sy62CC9EM27OvnfQZ45m8Rjt63LBa5x LztBrWKG1bMIYceFPXmC/LqpL4ameSSYWdWeyh596MZvOFladnugGtiT/ AgSDX60bNfnajYVFpgyZpEpqaqGO4jzUpfwMrcGBBmeUtB9E3HJT4cEGx 2nSc9JylQt3Xw1T8w2VHC9mHfBJdv3IjHg5qHDiUquk9KN9jWT9wR4jfh g==; X-IronPort-AV: E=McAfee;i="6500,9779,10481"; a="280637327" X-IronPort-AV: E=Sophos;i="5.93,345,1654585200"; d="scan'208";a="280637327" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2022 18:04:29 -0700 X-IronPort-AV: E=Sophos;i="5.93,345,1654585200"; d="scan'208";a="796142485" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2022 18:04:25 -0700 From: "Huang, Ying" To: Aneesh Kumar K V Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Wei Xu , Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Johannes Weiner , jvgediya.oss@gmail.com, Bharata B Rao Subject: Re: [PATCH v4] mm/demotion: Expose memory tier details via sysfs References: <20220922102201.62168-1-aneesh.kumar@linux.ibm.com> <874jwyjyy9.fsf@yhuang6-desk2.ccr.corp.intel.com> <3a966604-77c5-e6fc-1541-2fed7c71cc0c@linux.ibm.com> Date: Mon, 26 Sep 2022 09:04:16 +0800 In-Reply-To: <3a966604-77c5-e6fc-1541-2fed7c71cc0c@linux.ibm.com> (Aneesh Kumar K. V.'s message of "Fri, 23 Sep 2022 16:05:30 +0530") Message-ID: <87zgenhrov.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664154272; a=rsa-sha256; cv=none; b=m+a/gr+xUyw3IFySMDcQAAEvqWxqpfAcgqFb2Uzo9LpLFsAaSEVnJFfTtyrCpyBvM4tR9o 1LdO4hyEBazIWPj7C0FsSYRcfOH9D14glAaU+/14dIFU90GCvSoNC9VuNUE+pRlzL6Kzzx Lwl1EOloDjSLqVHh3QrvRyDlUtFgiFI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Jj4qB8Vl; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf07.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664154272; 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=DZE2+L2n4wi7creo1izZtSjC6xwX4niMXkdLIOZjbF0=; b=5Sz9yN4mMdxC0rm7vmyIrqp0Iv04/N4ZvEp94crkJui8qGyaowAAs8FoDlQH0D/WdAoq4o IIMswk3t0kGOicX+sCH3k5GkvfdBBJOBHPXq9kKp4d4Fep0Of9Yy/G4tG/uXkp6ksoXuib Imgw2a1/UAxcJSnsBd3vCwv2lxEvero= X-Rspam-User: X-Rspamd-Queue-Id: 651DB40004 X-Rspamd-Server: rspam08 X-Stat-Signature: ix1pbchzjuyy4wynr7mrz34rwmg9mjcm Authentication-Results: imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=Jj4qB8Vl; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf07.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-HE-Tag: 1664154271-916745 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: > On 9/23/22 1:37 PM, Huang, Ying wrote: >> "Aneesh Kumar K.V" writes: >>=20 >>> This patch adds /sys/devices/virtual/memory_tiering/ where all memory t= ier >>> 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 >>=20 >> It appears that XXXs is used for mask while XXXs_list is used for list? >> For example, >>=20 >> # cat /sys/devices/system/cpu/cpu2/topology/core_cpus >> 0,00100004 >> # cat /sys/devices/system/cpu/cpu2/topology/core_cpus_list >> 2,20 >>=20 >> It's better to follow the this convention? >>=20 > > That is not followed in other parts of the kernel. I was loking at cpuset= =20 > > $cat cpuset.cpus.effective=20 > 0-7 Per my understanding, cpuset isn't sysfs, but cgroupfs? I did some research in my system, $ grep . $(find /sys/devices | grep 'list$') and $ grep . $(find /sys/devices | grep 'cpus$') I found that the cpus/cpus_list convention is used in - pci /sys/devices/pci0000:64/0000:64:0d.2/local_cpulist:0-35 /sys/devices/pci0000:64/0000:64:0c.2/local_cpus:f,ffffffff - system /sys/devices/system/cpu/cpu7/topology/core_cpus_list:7,25 /sys/devices/system/cpu/cpu7/topology/core_cpus:0,02000080 - block /sys/devices/virtual/block/loop1/mq/0/cpu_list:0, 1, 2, ... - net /sys/devices/virtual/net/lo/queues/rx-0/rps_cpus:0,00000000 And I haven't found any exception in sysfs of my system. Can you find some? Best Regards, Huang, Ying >>> 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 >>> >>> :/sys/devices/virtual/memory_tiering$ cat memory_tier4/nodes >>> 0,2 >>> >>> Signed-off-by: Aneesh Kumar K.V >>=20 >> Best Regards, >> Huang, Ying >>=20 >> [snip]