Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Huang, Ying" <ying.huang@intel.com>
To:     Wei Xu <weixugc@google.com>, Johannes Weiner <hannes@cmpxchg.org>,
        Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Yang Shi <shy828301@gmail.com>,
        Tim C Chen <tim.c.chen@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Dan Williams <dan.j.williams@intel.com>
Cc:     Linux MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Michal Hocko <mhocko@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Hesham Almatary <hesham.almatary@huawei.com>,
        Alistair Popple <apopple@nvidia.com>, jvgediya.oss@gmail.com,
        Bharata B Rao <bharata@amd.com>
Subject: Re: [PATCH v2] mm/demotion: Expose memory tier details via sysfs
References: <20220829060745.287468-1-aneesh.kumar@linux.ibm.com>
        <CAAPL-u9HRHyQEw7q+bTUvYRQWwii7DWYyx3DCgmxJu+u3panbQ@mail.gmail.com>
        <22cb7a8a-84fe-04c7-41ea-50eff8184dc1@linux.ibm.com>
        <CAAPL-u-YuecdVsyr_Tdery8qqPDnzHxGaQL+CSO8x5xv8QH7kg@mail.gmail.com>
Date:   Thu, 01 Sep 2022 14:37:20 +0800
In-Reply-To: <CAAPL-u-YuecdVsyr_Tdery8qqPDnzHxGaQL+CSO8x5xv8QH7kg@mail.gmail.com>
        (Wei Xu's message of "Tue, 30 Aug 2022 00:17:18 -0700")
Message-ID: <8735db1ty7.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=ascii
Precedence: bulk

Wei Xu <weixugc@google.com> writes:

> On Mon, Aug 29, 2022 at 11:46 PM Aneesh Kumar K V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> On 8/30/22 12:01 PM, Wei Xu wrote:
>> > On Sun, Aug 28, 2022 at 11:08 PM Aneesh Kumar K.V
>> > <aneesh.kumar@linux.ibm.com> wrote:

[snip]

>> >>
>> >> +
>> >> +What:          /sys/devices/virtual/memory_tiering/memory_tierN/
>> >> +               /sys/devices/virtual/memory_tiering/memory_tierN/abstract_distance
>> >> +               /sys/devices/virtual/memory_tiering/memory_tierN/nodes
>> >> +Date:          August 2022
>> >> +Contact:       Linux memory management mailing list <linux-mm@kvack.org>
>> >> +Description:   Directory with details of a specific memory tier
>> >> +
>> >> +               This is the directory containing information about a particular
>> >> +               memory tier, memtierN, where N is derived based on abstract distance.
>> >> +
>> >> +               A smaller value of N implies a higher (faster) memory tier in the
>> >> +               hierarchy.
>> >
>> > Given that abstract_distance is provided, it would be more flexible if
>> > we don't commit to the interface where N in memtierN also indicates
>> > the memory tier ordering.
>>
>>
>> IIUC this is one of the request that Johannes had ie, to be able to understand the
>> memory tier hierarchy based on memtier name.
>>
>> >> +
>> >> +               abstract_distance: The abstract distance range this specific memory
>> >> +               tier maps to.
>> >
>> > I still think the name of "abstract distance" is kind of confusing
>> > because it is not clear what is the other object that this distance
>> > value is relative to.  Do we have to expose this value at this point
>> > if N in memtierN can already indicate the memory tier ordering?
>> >
>>
>> I do agree that abstract distance is confusing. But IIUC we agreed that it is much better
>> than other names suggested and is closer to already understood "numa distance" term.
>>
>> https://lore.kernel.org/linux-mm/YuLF%2FGG8x5lQvg%2Ff@cmpxchg.org/
>>
>
> "NUMA distance" measures the distance between two NUMA nodes.

Per my understanding, "NUMA distance" measures the distance between the
CPUs of one NUMA node to the memory of another NUMA node.

> I bring it up again because this name will become a user visible
> kernel interface, which we will need to live with for a long time.
> Even if we decide to keep the name, it would be better if we can
> define between which two (abstract) points the abstract distance
> reports.

My opinion is that "abstract distance" reflects the distance
(latency+bandwidth) between the CPUs of one NUMA socket to a type of
memory in the same NUMA socket.

Hi, Johannes,

What do you think about this?  You are the inventor of the "abstract
distance".  Can you elaborate its definition?

Best Regards,
Huang, Ying

> Another option is to remove this interface for now until it becomes
> necessary to report abstract distances to userspace.

[snip]