Linux CXL
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Dave Jiang <dave.jiang@intel.com>
Cc: <linux-kernel@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<rafael@kernel.org>, <linux-acpi@vger.kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH] base/node / acpi: Change 'node_hmem_attrs' to 'access_coordinates'
Date: Fri, 12 May 2023 08:58:14 -0700	[thread overview]
Message-ID: <645e6215ee0de_1e6f2945e@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20230510171445.00004cea@Huawei.com>

Jonathan Cameron wrote:
> On Fri, 05 May 2023 14:34:46 -0700
> Dave Jiang <dave.jiang@intel.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.

  reply	other threads:[~2023-05-12 15:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05 21:34 [PATCH] base/node / acpi: Change 'node_hmem_attrs' to 'access_coordinates' Dave Jiang
2023-05-10 16:14 ` Jonathan Cameron
2023-05-12 15:58   ` Dan Williams [this message]
2023-05-12 16:47     ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=645e6215ee0de_1e6f2945e@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=dave.jiang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox