linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Brice Goglin <Brice.Goglin@inria.fr>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-mm@kvack.org, linux-api@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rafael Wysocki <rafael@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCHv6 00/10] Heterogenous memory node attributes
Date: Tue, 19 Feb 2019 10:20:07 -0700	[thread overview]
Message-ID: <20190219172004.GD16341@localhost.localdomain> (raw)
In-Reply-To: <f2add663-a9e1-86df-0afd-22ef03d3d943@inria.fr>

On Mon, Feb 18, 2019 at 03:25:31PM +0100, Brice Goglin wrote:
> Le 14/02/2019 à 18:10, Keith Busch a écrit :
> >   Determining the cpu and memory node local relationships is quite
> >   different this time (PATCH 7/10). The local relationship to a memory
> >   target will be either *only* the node from the Initiator Proximity
> >   Domain if provided, or if it is not provided, all the nodes that have
> >   the same highest performance. Latency was chosen to take prioirty over
> >   bandwidth when ranking performance.
> 
> 
> Hello Keith
> 
> I am trying to understand what this last paragraph means.
> 
> Let's say I have a machine with DDR and NVDIMM both attached to the same
> socket, and I use Dave Hansen's kmem patchs to make the NVDIMM appear as
> "normal memory" in an additional NUMA node. Let's call node0 the DDR and
> node1 the NVDIMM kmem node.
> 
> Now user-space wants to find out which CPUs are actually close to the
> NVDIMMs. My understanding is that SRAT says that CPUs are local to the
> DDR only. Hence /sys/devices/system/node/node1/cpumap says there are no
> CPU local to the NVDIMM. And HMAT won't change this, right?

HMAT actually does change this. The relationship is in 6.2's HMAT
Address Range or 6.3's Proximity Domain Attributes, and that's
something SRAT wasn't providing.

The problem with these HMAT structures is that the CPU node is
optional. The last paragraph is saying that if that optional information
is provided, we will use that. If it is not provided, we will fallback
to performance attributes to determine what is the "local" CPU domain.
 
> Will node1 contain access0/initiators/node0 to clarify that CPUs local
> to the NVDIMM are those of node0? Even if latency from node0 to node1
> latency is higher than node0 to node0?

Exactly, yes. To expand on this, what you'd see from sysfs:

  /sys/devices/system/node/node0/access0/targets/node1 -> ../../../node1

And

  /sys/devices/system/node/node1/access0/initiators/node0 -> ../../../node0

> Another way to ask this: Is the latency/performance only used for
> distinguishing the local initiator CPUs among multiple CPU nodes
> accesing the same memory node? Or is it also used to distinguish the
> local memory target among multiple memories access by a single CPU node?

It's the first one. A single CPU domain may have multiple local targets,
but each of those targets may have different performance.

For example, you could have something like this with "normal" DDR
memory, high-bandwidth memory, and slower nvdimm:

 +------------------+    +------------------+
 | CPU Node 0       +----+ CPU Node 1       |
 | Node0 DDR Mem    |    | Node1 DDR Mem    |
 +--------+---------+    +--------+---------+
          |                       |
 +--------+---------+    +--------+---------+
 | Node2 HBMem      |    | Node3 HBMem      |
 +--------+---------+    +--------+---------+
          |                       |
 +--------+---------+    +--------+---------+
 | Node4 Slow NVMem |    | Node5 Slow NVMem |
 +------------------+    +------------------+

In the above, Initiator node0 is "local" to targets 0, 2, and 4, and
would show up in node0's access0/targets/. Each memory target node,
though, has different performance than the others that are local to the
same intiator domain.

> The Intel machine I am currently testing patches on doesn't have a HMAT
> in 1-level-memory unfortunately.

Platforms providing HMAT tables are still rare at the moment, but expect
will become more common.

  reply	other threads:[~2019-02-19 17:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 17:10 [PATCHv6 00/10] Heterogenous memory node attributes Keith Busch
2019-02-14 17:10 ` [PATCHv6 01/10] acpi: Create subtable parsing infrastructure Keith Busch
2019-02-14 17:10 ` [PATCHv6 02/10] acpi: Add HMAT to generic parsing tables Keith Busch
2019-02-14 17:10 ` [PATCHv6 03/10] acpi/hmat: Parse and report heterogeneous memory Keith Busch
2019-02-14 17:10 ` [PATCHv6 04/10] node: Link memory nodes to their compute nodes Keith Busch
2019-02-14 17:10 ` [PATCHv6 05/10] node: Add heterogenous memory access attributes Keith Busch
2019-02-14 17:10 ` [PATCHv6 06/10] node: Add memory-side caching attributes Keith Busch
2019-02-22 10:12   ` Brice Goglin
2019-02-22 18:09     ` Keith Busch
2019-02-22 18:20       ` Dan Williams
2019-02-22 10:22   ` Brice Goglin
2019-02-22 18:13     ` Keith Busch
2019-02-14 17:10 ` [PATCHv6 07/10] acpi/hmat: Register processor domain to its memory Keith Busch
2019-02-20 22:02   ` Rafael J. Wysocki
2019-02-20 22:11     ` Dave Hansen
2019-02-20 22:13       ` Dan Williams
2019-02-20 22:16         ` Rafael J. Wysocki
2019-02-20 22:20           ` Dan Williams
2019-02-20 22:21       ` Rafael J. Wysocki
2019-02-20 22:44         ` Keith Busch
2019-02-20 22:50           ` Rafael J. Wysocki
2019-02-22 18:48     ` Keith Busch
2019-02-22 19:21       ` Dan Williams
2019-02-24 20:07         ` Rafael J. Wysocki
2019-02-24 19:59       ` Rafael J. Wysocki
2019-02-25 16:51         ` Keith Busch
2019-02-25 22:30           ` Rafael J. Wysocki
2019-03-07 11:49   ` Brice Goglin
2019-03-07 15:19     ` Keith Busch
2019-02-14 17:10 ` [PATCHv6 08/10] acpi/hmat: Register performance attributes Keith Busch
2019-02-20 22:04   ` Rafael J. Wysocki
2019-02-14 17:10 ` [PATCHv6 09/10] acpi/hmat: Register memory side cache attributes Keith Busch
2019-02-20 22:05   ` Rafael J. Wysocki
2019-02-14 17:10 ` [PATCHv6 10/10] doc/mm: New documentation for memory performance Keith Busch
2019-02-18 14:25 ` [PATCHv6 00/10] Heterogenous memory node attributes Brice Goglin
2019-02-19 17:20   ` Keith Busch [this message]
2019-02-20 18:25 ` Keith Busch

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=20190219172004.GD16341@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=Brice.Goglin@inria.fr \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-api@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;
as well as URLs for NNTP newsgroup(s).