linux-kernel - Re: [PATCH v2] 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:   Tue, 13 Jun 2023 09:19:09 -0700
From:   Dave Jiang <dave.jiang@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     <linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
        <linux-cxl@...r.kernel.org>,
        Dan Williams <dan.j.williams@...el.com>, <rafael@...nel.org>,
        <jonathan.cameron@...wei.com>
Subject: Re: [PATCH v2] base/node / acpi: Change 'node_hmem_attrs' to
 'access_coordinates'


On 6/13/23 00:57, Greg KH wrote:
> On Mon, Jun 12, 2023 at 03:32:42PM -0700, Dave Jiang 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. The observation is that seemed like
>> an excercise in having the application identify "where" it falls on a
>> spectrum of bandwidth and latency needs. For the tuple of read/write-latency
>> and read/write-bandwidth, "coordinates" is not a perfect fit. Sometimes it
>> is just conveying values in isolation and 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. [2]
>>
>> Link: http://lore.kernel.org/r/64471313421f7_1b66294d5@dwillia2-xfh.jf.intel.com.notmuch/
>> Link: https://lore.kernel.org/linux-cxl/645e6215ee0de_1e6f2945e@dwillia2-xfh.jf.intel.com.notmuch/
>> Suggested-by: Dan Williams <dan.j.williams@...el.com>
>> Reviewed-by: Dan Williams <dan.j.williams@...el.com>
>> Signed-off-by: Dave Jiang <dave.jiang@...el.com>
>>
>> ---
>>
>> Hi Greg and Rafael,
>> please consider ACK this patch and Dan can take it through the
>> CXL upstream tree. The remaining ACPI [1] and CXL [2] patches for enabling
>> CXL QoS class data have dependency on this patch. Thank you!
>>
>> [1]: https://lore.kernel.org/linux-cxl/168333141100.2290593.16294670316057617744.stgit@djiang5-mobl3/T/#t
>> [2]: https://lore.kernel.org/linux-cxl/168451588868.3470703.3527256859632103687.stgit@djiang5-mobl3/T/#t
> Isn't this going to conflict with the version that I have in the
> driver-core-next tree as commit 7810f4dc8795 ("base/node: Use 'property'
> to identify an access parameter")?
>
> Or was that a different thing?

Yes this is a different thing and should not conflict. But a small 
dependency on the mentioned commit above however:

@@ -168,7 +168,7 @@ static ssize_t property##_show(struct device *dev,			\
  			   char *buf)					\
  {									\
  	return sysfs_emit(buf, "%u\n",					\
-			  to_access_nodes(dev)->hmem_attrs.property);	\
+			  to_access_nodes(dev)->coord.property);	\
  }									\
  static DEVICE_ATTR_RO(property)
  


>
> thanks,
>
> greg k-h