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 C825CC433FE for ; Thu, 12 May 2022 07:19:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CB1B6B0074; Thu, 12 May 2022 03:19:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 552AA6B0075; Thu, 12 May 2022 03:19:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4012B6B0078; Thu, 12 May 2022 03:19:15 -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 2ACCF6B0074 for ; Thu, 12 May 2022 03:19:15 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id DCEAF80262 for ; Thu, 12 May 2022 07:19:14 +0000 (UTC) X-FDA: 79456239828.31.2660409 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf29.hostedemail.com (Postfix) with ESMTP id C71C61200C0 for ; Thu, 12 May 2022 07:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652339951; x=1683875951; h=message-id:subject:from:to:date:in-reply-to:references: mime-version:content-transfer-encoding; bh=YgDjZJ0GrhB2TixzXN5MHJpkRl2ysRB6/EQ97IsEbNI=; b=hLTqP1IuNHc28juB2T2Oi34Zhf1p/aCDpr0vqDOZHBsFVgvckOVxqotV wrKoaS1utm1OLdgEWwonvnUZ9Brxpimv7S5xeMFZb+D/RmJHy9RCEfstZ QgvxTdJlvs0CyCqFDEP/4SAuae1aF12QnOht7/6EDCy4fcyROCkpXNLV1 7zpFommJ8CapLMdmYoPC+LfsKPv45ZJczile7p0tuqWe0BQND9hZsARow vrXn+6jEkAQzYk9E5X1TXC5jEiIbh5MI7OJ8elPsfsqMYH6K8SdGjhEIG 06lr/7VWg0bnYSD+JWC+MZ23mdBF6ZgRcykDKgNQZZ7lCo63odf5APeoN w==; X-IronPort-AV: E=McAfee;i="6400,9594,10344"; a="268753314" X-IronPort-AV: E=Sophos;i="5.91,219,1647327600"; d="scan'208";a="268753314" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2022 00:18:36 -0700 X-IronPort-AV: E=Sophos;i="5.91,219,1647327600"; d="scan'208";a="566550286" Received: from ruonanwa-mobl.ccr.corp.intel.com ([10.254.212.157]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2022 00:18:30 -0700 Message-ID: <9c93f72ad70687d06e9318f8023ce45d39f742e3.camel@intel.com> Subject: Re: RFC: Memory Tiering Kernel Interfaces (v2) From: "ying.huang@intel.com" To: Aneesh Kumar K V , Wei Xu , Andrew Morton , Greg Thelen , Yang Shi , Linux Kernel Mailing List , Jagdish Gediya , Michal Hocko , Tim C Chen , Dave Hansen , Alistair Popple , Baolin Wang , Feng Tang , Jonathan Cameron , Davidlohr Bueso , Dan Williams , David Rientjes , Linux MM , Brice Goglin , Hesham Almatary Date: Thu, 12 May 2022 15:18:27 +0800 In-Reply-To: References: <56b41ce6922ed5f640d9bd46a603fa27576532a9.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: C71C61200C0 X-Stat-Signature: nb9fcf36ip11djjibgk3fsg8u9rs884d Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hLTqP1Iu; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf29.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1652339944-854819 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: On Thu, 2022-05-12 at 12:42 +0530, Aneesh Kumar K V wrote: > On 5/12/22 12:33 PM, ying.huang@intel.com wrote: > > On Wed, 2022-05-11 at 23:22 -0700, Wei Xu wrote: > > > Sysfs Interfaces > > > ================ > > > > > > * /sys/devices/system/memtier/memtierN/nodelist > > > > > >    where N = 0, 1, 2 (the kernel supports only 3 tiers for now). > > > > > >    Format: node_list > > > > > >    Read-only. When read, list the memory nodes in the specified tier. > > > > > >    Tier 0 is the highest tier, while tier 2 is the lowest tier. > > > > > >    The absolute value of a tier id number has no specific meaning. > > >    What matters is the relative order of the tier id numbers. > > > > > >    When a memory tier has no nodes, the kernel can hide its memtier > > >    sysfs files. > > > > > > * /sys/devices/system/node/nodeN/memtier > > > > > >    where N = 0, 1, ... > > > > > >    Format: int or empty > > > > > >    When read, list the memory tier that the node belongs to. Its value > > >    is empty for a CPU-only NUMA node. > > > > > >    When written, the kernel moves the node into the specified memory > > >    tier if the move is allowed. The tier assignment of all other nodes > > >    are not affected. > > > > > >    Initially, we can make this interface read-only. > > > > It seems that "/sys/devices/system/node/nodeN/memtier" has all > > information we needed. Do we really need > > "/sys/devices/system/memtier/memtierN/nodelist"? > > > > That can be gotten via a simple shell command line, > > > > $ grep . /sys/devices/system/node/nodeN/memtier | sort -n -k 2 -t ':' > > > > It will be really useful to fetch the memory tier node list in an easy > fashion rather than reading multiple sysfs directories. If we don't have > other attributes for memorytier, we could keep > "/sys/devices/system/memtier/memtierN" a NUMA node list there by > avoiding /sys/devices/system/memtier/memtierN/nodelist This will make the interface not extensible. Even a single file "/sys/devices/system/node/memtiers" is better. As an readonly file, it should be OK to put multiple values in it. I remember that one rule for sysfs is that it is accessed more via libsysfs. Does that make life easier? Best Regards, Huang, Ying