On Thu, Feb 14, 2019 at 6:10 PM Keith Busch <keith.busch@xxxxxxxxx> wrote: > > If the HMAT Subsystem Address Range provides a valid processor proximity > domain for a memory domain, or a processor domain matches the performance > access of the valid processor proximity domain, register the memory > target with that initiator so this relationship will be visible under > the node's sysfs directory. > > By registering only the best performing relationships, this provides the > most useful information applications may want to know when considering > which CPU they should run on for a given memory node, or which memory > node they should allocate memory from for a given CPU. > > Since HMAT requires valid address ranges have an equivalent SRAT entry, > verify each memory target satisfies this requirement. > > Signed-off-by: Keith Busch <keith.busch@xxxxxxxxx> > --- > drivers/acpi/hmat/Kconfig | 1 + > drivers/acpi/hmat/hmat.c | 396 +++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 396 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/hmat/Kconfig b/drivers/acpi/hmat/Kconfig > index c9637e2e7514..08e972ead159 100644 > --- a/drivers/acpi/hmat/Kconfig > +++ b/drivers/acpi/hmat/Kconfig > @@ -2,6 +2,7 @@ > config ACPI_HMAT > bool "ACPI Heterogeneous Memory Attribute Table Support" > depends on ACPI_NUMA > + select HMEM_REPORTING If you want to do this here, I'm not sure that defining HMEM_REPORTING as a user-selectable option is a good idea. In particular, I don't really think that setting ACPI_HMAT without it makes a lot of sense. Apart from this, the patch looks reasonable to me.
