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] [day] [month] [year] [list]
Message-ID: <2023061533-paralyze-tinker-3d32@gregkh>
Date:   Thu, 15 Jun 2023 13:24:41 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Dave Jiang <dave.jiang@...el.com>
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 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

Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ