linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-mm@kvack.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>,
	linuxarm@huawei.com
Subject: Re: [PATCHv5 00/10] Heterogeneuos memory node attributes
Date: Wed, 6 Feb 2019 10:19:37 -0700	[thread overview]
Message-ID: <20190206171935.GJ28064@localhost.localdomain> (raw)
In-Reply-To: <20190206123100.0000094a@huawei.com>

On Wed, Feb 06, 2019 at 12:31:00PM +0000, Jonathan Cameron wrote:
> On Thu, 24 Jan 2019 16:07:14 -0700
> Keith Busch <keith.busch@intel.com> wrote:
> 
> 1) It seems this version added a hard dependence on having the memory node
>    listed in the Memory Proximity Domain attribute structures.  I'm not 100%
>    sure there is actually any requirement to have those structures. If you aren't
>    using the hint bit, they don't convey any information.  It could be argued
>    that they provide info on what is found in the other hmat entries, but there
>    is little purpose as those entries are explicit in what the provide.
>    (Given I didn't have any of these structures and things  worked fine with
>     v4 it seems this is a new check).

Right, v4 just used the node(s) with the highest performance. You mentioned
systems having nodes with different performance, but no winner across all
attributes, so there's no clear way to rank these for access class linkage.
Requiring an initiator PXM present clears that up.

Maybe we can fallback to performance if the initiator pxm isn't provided,
but the ranking is going to require an arbitrary decision, like prioritize
latency over bandwidth.
 
>    This is also somewhat inconsistent.
>    a) If a given entry isn't there, we still get for example
>       node4/access0/initiators/[read|write]_* but all values are 0.
>       If we want to do the check you have it needs to not create the files in
>       this case.  Whilst they have no meaning as there are no initiators, it
>       is inconsistent to my mind.
> 
>    b) Having one "Memory Proximity Domain attribute structure" for node 4 linking
>       it to node0 is sufficient to allow
>       node4/access0/initiators/node0
>       node4/access0/initiators/node1
>       node4/access0/initiators/node2
>       node4/access0/initiators/node3
>       I think if we are going to enforce the presence of that structure then only
>       the node0 link should exist.

We'd link the initiator pxm in the Address Range Structure, and also any
other nodes with identical performance access. I think that makes sense.
 
> 2) Error handling could perhaps do to spit out some nasty warnings.
>    If we have an entry for nodes that don't exist we shouldn't just fail silently,
>    that's just one example I managed to trigger with minor table tweaking.
> 
> Personally I would just get rid of enforcing anything based on the presence of
> that structure.


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

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 23:07 [PATCHv5 00/10] Heterogeneuos memory node attributes Keith Busch
2019-01-24 23:07 ` [PATCHv5 01/10] acpi: Create subtable parsing infrastructure Keith Busch
2019-01-24 23:07 ` [PATCHv5 02/10] acpi: Add HMAT to generic parsing tables Keith Busch
2019-01-24 23:07 ` [PATCHv5 03/10] acpi/hmat: Parse and report heterogeneous memory Keith Busch
2019-02-05 12:12   ` Rafael J. Wysocki
2019-02-06 12:28   ` Jonathan Cameron
2019-02-06 16:06     ` Keith Busch
2019-02-06 16:39       ` Jonathan Cameron
2019-01-24 23:07 ` [PATCHv5 04/10] node: Link memory nodes to their compute nodes Keith Busch
2019-02-05 12:33   ` Rafael J. Wysocki
2019-02-05 14:48     ` Keith Busch
2019-02-05 14:52     ` Greg Kroah-Hartman
2019-02-05 15:17       ` Rafael J. Wysocki
2019-02-06 23:09         ` Keith Busch
2019-02-06 23:48           ` Rafael J. Wysocki
2019-02-06 12:26   ` Jonathan Cameron
2019-02-06 16:12     ` Keith Busch
2019-02-06 16:47       ` Jonathan Cameron
2019-02-07 11:35   ` Rafael J. Wysocki
2019-01-24 23:07 ` [PATCHv5 05/10] acpi/hmat: Register processor domain to its memory Keith Busch
2019-02-06 12:26   ` Jonathan Cameron
2019-01-24 23:07 ` [PATCHv5 06/10] node: Add heterogenous memory access attributes Keith Busch
2019-01-24 23:07 ` [PATCHv5 07/10] acpi/hmat: Register performance attributes Keith Busch
2019-02-06 12:24   ` Jonathan Cameron
2019-01-24 23:07 ` [PATCHv5 08/10] node: Add memory caching attributes Keith Busch
2019-02-06 12:24   ` Jonathan Cameron
2019-01-24 23:07 ` [PATCHv5 09/10] acpi/hmat: Register memory side cache attributes Keith Busch
2019-02-06 12:17   ` Jonathan Cameron
2019-01-24 23:07 ` [PATCHv5 10/10] doc/mm: New documentation for memory performance Keith Busch
2019-02-06 10:45   ` Jonathan Cameron
2019-02-06 16:25     ` Keith Busch
2019-01-28 14:00 ` [PATCHv5 00/10] Heterogeneuos memory node attributes Michal Hocko
2019-02-06 12:31 ` Jonathan Cameron
2019-02-06 17:19   ` Keith Busch [this message]
2019-02-06 17:30     ` Jonathan Cameron
2019-02-07  9:53 ` Jonathan Cameron
2019-02-07 15:08   ` 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=20190206171935.GJ28064@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxarm@huawei.com \
    --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).