linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Keith Busch <keith.busch@intel.com>
Cc: Brice Goglin <Brice.Goglin@inria.fr>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	Rafael Wysocki <rafael@kernel.org>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCHv4 10/13] node: Add memory caching attributes
Date: Tue, 12 Feb 2019 08:49:03 +0000	[thread overview]
Message-ID: <20190212084903.00003ff5@huawei.com> (raw)
In-Reply-To: <20190211152303.GA4525@localhost.localdomain>

On Mon, 11 Feb 2019 08:23:04 -0700
Keith Busch <keith.busch@intel.com> wrote:

> On Sun, Feb 10, 2019 at 09:19:58AM -0800, Jonathan Cameron wrote:
> > On Sat, 9 Feb 2019 09:20:53 +0100
> > Brice Goglin <Brice.Goglin@inria.fr> wrote:
> >   
> > > Hello Keith
> > > 
> > > Could we ever have a single side cache in front of two NUMA nodes ? I
> > > don't see a way to find that out in the current implementation. Would we
> > > have an "id" and/or "nodemap" bitmask in the sidecache structure ?  
> > 
> > This is certainly a possible thing for hardware to do.
> >
> > ACPI IIRC doesn't provide any means of representing that - your best
> > option is to represent it as two different entries, one for each of the
> > memory nodes.  Interesting question of whether you would then claim
> > they were half as big each, or the full size.  Of course, there are
> > other possible ways to get this info beyond HMAT, so perhaps the interface
> > should allow it to be exposed if available?  
> 
> HMAT doesn't do this, but I want this interface abstracted enough from
> HMAT to express whatever is necessary.
> 
> The CPU cache is the closest existing exported attributes to this,
> and they provide "shared_cpu_list". To that end, I can export a
> "shared_node_list", though previous reviews strongly disliked multi-value
> sysfs entries. :(
> 
> Would shared-node symlinks capture the need, and more acceptable?

My inclination is that it's better to follow an existing pattern than
invent a new one that breaks people's expectations.

However, don't feel that strongly about it as long as the interface
is functional and intuitive.


>  
> > Also, don't know if it's just me, but calling these sidecaches is
> > downright confusing.  In ACPI at least they are always
> > specifically referred to as Memory Side Caches.
> > I'd argue there should even by a hyphen Memory-Side Caches, the point
> > being that that they are on the memory side of the interconnected
> > rather than the processor side.  Of course an implementation
> > choice might be to put them off to the side (as implied by sidecaches)
> > in some sense, but it's not the only one.
> > 
> > </terminology rant> :)  
> 
> Now that you mention it, I agree "side" is ambiguous.  Maybe call it
> "numa_cache" or "node_cache"?
I'm not sure any of the options work well.  My inclination would be to
use the full name and keep the somewhat redundant memory there.

The other two feel like they could just as easily be coherent caches
at accelerators for example...

memory_side_cache?

The fun of naming ;)

Jonathan


  parent reply	other threads:[~2019-02-12  8:49 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 17:57 [PATCHv4 00/13] Heterogeneuos memory node attributes Keith Busch
2019-01-16 17:57 ` [PATCHv4 01/13] acpi: Create subtable parsing infrastructure Keith Busch
2019-01-16 17:57 ` [PATCHv4 02/13] acpi: Add HMAT to generic parsing tables Keith Busch
2019-01-16 17:57 ` [PATCHv4 03/13] acpi/hmat: Parse and report heterogeneous memory Keith Busch
2019-01-17 11:00   ` Rafael J. Wysocki
2019-01-17 11:00     ` Rafael J. Wysocki
2019-01-16 17:57 ` [PATCHv4 04/13] node: Link memory nodes to their compute nodes Keith Busch
2019-01-17 11:26   ` Rafael J. Wysocki
2019-01-17 11:26     ` Rafael J. Wysocki
2019-01-16 17:57 ` [PATCHv4 05/13] Documentation/ABI: Add new node sysfs attributes Keith Busch
2019-01-17 11:41   ` Rafael J. Wysocki
2019-01-17 11:41     ` Rafael J. Wysocki
2019-01-18 20:42     ` Keith Busch
2019-01-18 21:08     ` Dan Williams
2019-01-18 21:08       ` Dan Williams
2019-01-19  9:01       ` Greg Kroah-Hartman
2019-01-19 16:56         ` Dan Williams
2019-01-19 16:56           ` Dan Williams
2019-01-20 16:19           ` Rafael J. Wysocki
2019-01-20 16:19             ` Rafael J. Wysocki
2019-01-20 17:34             ` Dan Williams
2019-01-20 17:34               ` Dan Williams
2019-01-21  9:54               ` Rafael J. Wysocki
2019-01-21  9:54                 ` Rafael J. Wysocki
2019-01-20 16:16         ` Rafael J. Wysocki
2019-01-20 16:16           ` Rafael J. Wysocki
2019-01-22 16:36           ` Keith Busch
2019-01-22 16:51             ` Rafael J. Wysocki
2019-01-22 16:51               ` Rafael J. Wysocki
2019-01-22 16:54               ` Rafael J. Wysocki
2019-01-22 16:54                 ` Rafael J. Wysocki
2019-01-18 11:21   ` Jonathan Cameron
2019-01-18 11:21     ` Jonathan Cameron
2019-01-18 16:35     ` Dan Williams
2019-01-18 16:35       ` Dan Williams
2019-01-16 17:57 ` [PATCHv4 06/13] acpi/hmat: Register processor domain to its memory Keith Busch
2019-01-17 12:11   ` Rafael J. Wysocki
2019-01-17 12:11     ` Rafael J. Wysocki
2019-01-17 17:01     ` Dan Williams
2019-01-17 17:01       ` Dan Williams
2019-01-16 17:57 ` [PATCHv4 07/13] node: Add heterogenous memory access attributes Keith Busch
2019-01-17 15:03   ` Rafael J. Wysocki
2019-01-17 15:03     ` Rafael J. Wysocki
2019-01-17 15:41     ` Greg Kroah-Hartman
2019-01-16 17:57 ` [PATCHv4 08/13] Documentation/ABI: Add node performance attributes Keith Busch
2019-01-17 15:09   ` Rafael J. Wysocki
2019-01-17 15:09     ` Rafael J. Wysocki
2019-01-16 17:58 ` [PATCHv4 09/13] acpi/hmat: Register " Keith Busch
2019-01-17 15:21   ` Rafael J. Wysocki
2019-01-16 17:58 ` [PATCHv4 10/13] node: Add memory caching attributes Keith Busch
2019-01-17 16:00   ` Rafael J. Wysocki
2019-01-17 16:00     ` Rafael J. Wysocki
2019-02-09  8:20   ` Brice Goglin
2019-02-10 17:19     ` Jonathan Cameron
2019-02-11 15:23       ` Keith Busch
2019-02-12  8:11         ` Brice Goglin
2019-02-12  8:49         ` Jonathan Cameron [this message]
2019-02-12 17:31           ` Keith Busch
2019-01-16 17:58 ` [PATCHv4 11/13] Documentation/ABI: Add node cache attributes Keith Busch
2019-01-17 16:25   ` Rafael J. Wysocki
2019-01-17 16:25     ` Rafael J. Wysocki
2019-01-16 17:58 ` [PATCHv4 12/13] acpi/hmat: Register memory side " Keith Busch
2019-01-17 17:42   ` Rafael J. Wysocki
2019-01-17 17:42     ` Rafael J. Wysocki
2019-01-16 17:58 ` [PATCHv4 13/13] doc/mm: New documentation for memory performance Keith Busch
2019-01-17 12:58 ` [PATCHv4 00/13] Heterogeneuos memory node attributes Balbir Singh
2019-01-17 15:44   ` Keith Busch
2019-01-18 13:16     ` Balbir Singh
2019-01-17 18:18 ` Jonathan Cameron
2019-01-17 18:18   ` Jonathan Cameron
2019-01-17 19:47   ` Keith Busch
2019-01-18 11:12     ` 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=20190212084903.00003ff5@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Brice.Goglin@inria.fr \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keith.busch@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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