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 035C8ECAAD2 for ; Fri, 2 Sep 2022 00:33:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 734478008A; Thu, 1 Sep 2022 20:33:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E2948D0001; Thu, 1 Sep 2022 20:33:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AB638008A; Thu, 1 Sep 2022 20:33:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4CC4B8D0001 for ; Thu, 1 Sep 2022 20:33:09 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2832680B5B for ; Fri, 2 Sep 2022 00:33:09 +0000 (UTC) X-FDA: 79865270898.31.BC2739B Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf14.hostedemail.com (Postfix) with ESMTP id 6136810002B for ; Fri, 2 Sep 2022 00:33:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662078788; x=1693614788; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=8qubwDEk7bK1thYQZ5HsOms2XEz5Np/BfJ6RKgPJUN8=; b=ioT1Tt0QoDBLA7kjF7Q6Bu2pf9y9pMrRGNNuRGqfS27fKyhANDQ0E5t7 XRjAT3Y8WTYQgrD+o062Iaa96SDkPv0SnUMEa+2HRff81qcKraRk8aa4L bzdhr1mvlLTRsLayfRLNlMCM/+I4A3qqYniljCwdezSZgYmDsiA/V+Fzq WKHhsEz3zlgXllS/kDOKZlE6J7GkQ3LMZ4FF1CCCwGY/kQa3h9b2/lw3U tUyIJcAE7zQSxIh2RRTBuKIPTtPYKhzdkeEI+xOMRSwNtYW9+nlosLxT0 aLfSogDq+xTqsbR2ISbVoyebdjfDKWPiQ+ysyPerPoASlZGiaqv2g5j/+ g==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="293438024" X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="293438024" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 17:33:06 -0700 X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="563716721" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 17:33:02 -0700 From: "Huang, Ying" To: Aneesh Kumar K V , Wei Xu Cc: Johannes Weiner , 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> <87tu5rzigc.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Fri, 02 Sep 2022 08:29:54 +0800 In-Reply-To: (Aneesh Kumar K. V.'s message of "Thu, 1 Sep 2022 13:54:27 +0530") Message-ID: <87pmgezkhp.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=1662078788; a=rsa-sha256; cv=none; b=Mc75yKvyuMpPdsWDFEd5W/MZ1zNB9ImnBp9eca3t8MttnO87Q+rKpy0mBKZnwt+ilLzjJu /nR5ONxx32PGpNdNPDZRLuWX6rJ2SRs3QkaI7oPBQ1B055OrAIVq12M69fO18WNJcntWZk UrZOTCLU7nm1BOVRfKq7qGoY5SUAPLw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=ioT1Tt0Q; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=softfail (imf14.hostedemail.com: 192.55.52.93 is neither permitted nor denied by domain of ying.huang@intel.com) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662078788; 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=9z0CvUx3V0HkCHksFBYODqHM4mC725Hc7HHlIM9jjSY=; b=L8R9HcoFPAChqanjGhqdrzNFrQuqYw3PA8oZw9EtQeXXdPPZap7AtMhqaAgaqeJgAEVe4J v38r19d12Ait1B7vENWqKELIjEekXypQibqMbCaGldPJGHubxB6T2ejtfRwW2pwTZPYkCH Q8c/WSnBh5Nin1Wbi0aKlh0lfWhj3dg= X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6136810002B Authentication-Results: imf14.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=ioT1Tt0Q; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=softfail (imf14.hostedemail.com: 192.55.52.93 is neither permitted nor denied by domain of ying.huang@intel.com) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Stat-Signature: kq1xw1jns64ztigkcgoe4tk86zchfx7g X-HE-Tag: 1662078788-149488 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/1/22 12:31 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 >> 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. >>=20 >>> >>> 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 >>=20 >> 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. >>=20 > > > In the case you describe above and others, we will always have a list of > NUMA nodes from which memory promotion is not done. > /sys/devices/virtual/memory_tiering/toptier_nodes shows that list. I don't think we will need that interface if we don't restrict promotion in the future. For example, he can just check the memory tier with smallest number. TBH, I don't know why do we need that interface. What is it for? We don't want to expose unnecessary information to restrict our in kernel implementation in the future. So, please remove that interface at least before we discussing it thoroughly. >> Do we need a way to show the default memory tier in sysfs? That is, the >> memory tier that the DRAM nodes belong to. >>=20 > > I will hold adding that until we have support for modifying memory tier d= etails from > userspace. That is when userspace would want to know about the default me= mory tier.=20 > > For now, the user interface is a simpler hierarchy of memory tiers, it's = associated > nodes and the list of nodes from which promotion is not done. OK. Best Regards, Huang, Ying