Message-ID: <20190528123158.0000167a@huawei.com>
Date:   Tue, 28 May 2019 12:31:58 +0100
From:   Jonathan Cameron <jonathan.cameron@...wei.com>
To:     <linux-mm@...ck.org>, <linux-acpi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
CC:     Jérôme Glisse <jglisse@...hat.com>,
        Keith Busch <keith.busch@...el.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>, <linuxarm@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/4 V3] ACPI: Support generic initiator proximity
 domains

Hi All,

Anyone had a change to take a look at this?

Thanks,

Jonathan

On Tue, 16 Apr 2019 01:49:03 +0800
Jonathan Cameron <Jonathan.Cameron@...wei.com> wrote:

> Changes since RFC V2.
> * RFC dropped as now we have x86 support, so the lack of guards in in the
> ACPI code etc should now be fine.
> * Added x86 support.  Note this has only been tested on QEMU as I don't have
> a convenient x86 NUMA machine to play with.  Note that this fitted together
> rather differently form arm64 so I'm particularly interested in feedback
> on the two solutions.
> 
> Since RFC V1.
> * Fix incorrect interpretation of the ACPI entry noted by Keith Busch
> * Use the acpica headers definitions that are now in mmotm.
> 
> It's worth noting that, to safely put a given device in a GI node, may
> require changes to the existing drivers as it's not unusual to assume
> you have local memory or processor core. There may be futher constraints
> not yet covered by this patch.
> 
> Original cover letter...
> 
> ACPI 6.3 introduced a new entity that can be part of a NUMA proximity domain.
> It may share such a domain with the existing options (memory, cpu etc) but it
> may also exist on it's own.
> 
> The intent is to allow the description of the NUMA properties (particulary
> via HMAT) of accelerators and other initiators of memory activity that are not
> the host processor running the operating system.
> 
> This patch set introduces 'just enough' to make them work for arm64 and x86.
> It should be trivial to support other architectures, I just don't suitable
> NUMA systems readily available to test.
> 
> There are a few quirks that need to be considered.
> 
> 1. Fall back nodes
> ******************
> 
> As pre ACPI 6.3 supporting operating systems do not have Generic Initiator
> Proximity Domains it is possible to specify, via _PXM in DSDT that another
> device is part of such a GI only node.  This currently blows up spectacularly.
> 
> Whilst we can obviously 'now' protect against such a situation (see the related
> thread on PCI _PXM support and the  threadripper board identified there as
> also falling into the  problem of using non existent nodes
> https://patchwork.kernel.org/patch/10723311/ ), there is no way to  be sure
> we will never have legacy OSes that are not protected  against this.  It would
> also be 'non ideal' to fallback to  a default node as there may be a better
> (non GI) node to pick  if GI nodes aren't available.
> 
> The work around is that we also have a new system wide OSC bit that allows
> an operating system to 'annouce' that it supports Generic Initiators.  This
> allows, the firmware to us DSDT magic to 'move' devices between the nodes
> dependent on whether our new nodes are there or not.
> 
> 2. New ways of assigning a proximity domain for devices
> *******************************************************
> 
> Until now, the only way firmware could indicate that a particular device
> (outside the 'special' set of cpus etc) was to be found in a particular
> Proximity Domain by the use of _PXM in DSDT.
> 
> That is equally valid with GI domains, but we have new options. The SRAT
> affinity structure includes a handle (ACPI or PCI) to identify devices
> with the system and specify their proximity domain that way.  If both _PXM
> and this are provided, they should give the same answer.
> 
> For now this patch set completely ignores that feature as we don't need
> it to start the discussion.  It will form a follow up set at some point
> (if no one else fancies doing it).
> 
> Jonathan Cameron (4):
>   ACPI: Support Generic Initiator only domains
>   arm64: Support Generic Initiator only domains
>   x86: Support Generic Initiator only proximity domains
>   ACPI: Let ACPI know we support Generic Initiator Affinity Structures
> 
>  arch/arm64/kernel/smp.c        |  8 +++++
>  arch/x86/include/asm/numa.h    |  2 ++
>  arch/x86/kernel/setup.c        |  1 +
>  arch/x86/mm/numa.c             | 14 ++++++++
>  drivers/acpi/bus.c             |  1 +
>  drivers/acpi/numa.c            | 62 +++++++++++++++++++++++++++++++++-
>  drivers/base/node.c            |  3 ++
>  include/asm-generic/topology.h |  3 ++
>  include/linux/acpi.h           |  1 +
>  include/linux/nodemask.h       |  1 +
>  include/linux/topology.h       |  7 ++++
>  11 files changed, 102 insertions(+), 1 deletion(-)
> 

Powered by blists - more mailing lists