linux-kernel - Re: [PATCH] base/node / acpi: Change 'node_hmem_attrs' to 'access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 12 May 2023 08:58:14 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Dave Jiang <dave.jiang@...el.com>
CC:     <linux-kernel@...r.kernel.org>, <gregkh@...uxfoundation.org>,
        <rafael@...nel.org>, <linux-acpi@...r.kernel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH] base/node / acpi: Change 'node_hmem_attrs' to
 'access_coordinates'

Jonathan Cameron wrote:
> On Fri, 05 May 2023 14:34:46 -0700
> Dave Jiang <dave.jiang@...el.com> wrote:
> 
> > Dan Williams suggested changing the struct 'node_hmem_attrs' to
> > 'access_coordinates' [1]. The struct is a container of r/w-latency and
> > r/w-bandwidth numbers. Moving forward, this container will also be used by
> > CXL to store the performance characteristics of each link hop in
> > the PCIE/CXL topology. So, where node_hmem_attrs is just the access
> > parameters of a memory-node, access_coordinates applies more broadly
> > to hardware topology characteristics.
> 
> Not that it hugely matters, but why the term "coordinates"?
> Looks like Dan used that term, but I've not come across it being applied
> in this circumstances and it isn't a case of being immediately obvious
> to me what it means.
> 
> If it is just another vague entry in kernel word soup then I don't really
> mind the term, but nice to give some reasoning in patch description.

The inspiration here was past discussions that have been had about
potential API changes for userspace contending with multiple memory
types. The observation was that seemed like an exercise in having the
application identify "where" it falls on a spectrum of bandwidth and
latency needs.

So it's a tuple of read/write-latency and read/write-bandwidth.
"Coordinates" is not a perfect fit. Sometimes it is just conveying
values in isolation not a "location" relative to other performance
points, but in the end this data is used to identify the performance
operation point of a given memory-node.