mbox series

[PATCHv8,00/10] Heterogenous memory node attributes

Message ID 20190311205606.11228-1-keith.busch@intel.com (mailing list archive)
Headers show
Series Heterogenous memory node attributes | expand

Message

Keith Busch March 11, 2019, 8:55 p.m. UTC 
== Changes since v7 ==

  Fixed an early return that prevented reporting HMAT when there are no
  direct attached initiators.

  Fixed introducing a variable that was unused until several patches
  later.

  Miscellaneous typos, editorial clarifications, and whitespace fixups.

  Merged to most current linux-next.

  Added received review, test, and ack by's.

I've published a git tree available on this branch:

  https://git.kernel.org/pub/scm/linux/kernel/git/kbusch/linux.git/log/?h=hmat-v8

== Background ==

Platforms may provide multiple types of cpu attached system memory. The
memory ranges for each type may have different characteristics that
applications may wish to know about when considering what node they want
their memory allocated from.

It had previously been difficult to describe these setups as memory
rangers were generally lumped into the NUMA node of the CPUs. New
platform attributes have been created and in use today that describe
the more complex memory hierarchies that can be created.

This series' objective is to provide the attributes from such systems
that are useful for applications to know about, and readily usable with
existing tools and libraries. Those applications may query performance
attributes relative to a particular CPU they're running on in order to
make more informed choices for where they want to allocate hot and cold
data. This works with mbind() or the numactl library.

Keith Busch (10):
  acpi: Create subtable parsing infrastructure
  acpi: Add HMAT to generic parsing tables
  acpi/hmat: Parse and report heterogeneous memory
  node: Link memory nodes to their compute nodes
  node: Add heterogenous memory access attributes
  node: Add memory-side caching attributes
  acpi/hmat: Register processor domain to its memory
  acpi/hmat: Register performance attributes
  acpi/hmat: Register memory side cache attributes
  doc/mm: New documentation for memory performance

 Documentation/ABI/stable/sysfs-devices-node   |  87 +++-
 Documentation/admin-guide/mm/numaperf.rst     | 169 +++++++
 arch/arm64/kernel/acpi_numa.c                 |   2 +-
 arch/arm64/kernel/smp.c                       |   4 +-
 arch/ia64/kernel/acpi.c                       |  16 +-
 arch/x86/kernel/acpi/boot.c                   |  36 +-
 drivers/acpi/Kconfig                          |   1 +
 drivers/acpi/Makefile                         |   1 +
 drivers/acpi/hmat/Kconfig                     |  11 +
 drivers/acpi/hmat/Makefile                    |   1 +
 drivers/acpi/hmat/hmat.c                      | 666 ++++++++++++++++++++++++++
 drivers/acpi/numa.c                           |  16 +-
 drivers/acpi/scan.c                           |   4 +-
 drivers/acpi/tables.c                         |  76 ++-
 drivers/base/Kconfig                          |   8 +
 drivers/base/node.c                           | 352 +++++++++++++-
 drivers/irqchip/irq-gic-v2m.c                 |   2 +-
 drivers/irqchip/irq-gic-v3-its-pci-msi.c      |   2 +-
 drivers/irqchip/irq-gic-v3-its-platform-msi.c |   2 +-
 drivers/irqchip/irq-gic-v3-its.c              |   6 +-
 drivers/irqchip/irq-gic-v3.c                  |  10 +-
 drivers/irqchip/irq-gic.c                     |   4 +-
 drivers/mailbox/pcc.c                         |   2 +-
 include/linux/acpi.h                          |   6 +-
 include/linux/node.h                          |  71 +++
 25 files changed, 1489 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/admin-guide/mm/numaperf.rst
 create mode 100644 drivers/acpi/hmat/Kconfig
 create mode 100644 drivers/acpi/hmat/Makefile
 create mode 100644 drivers/acpi/hmat/hmat.c

Comments

Brice Goglin March 11, 2019, 11:06 p.m. UTC | #1 
Le 11/03/2019 à 21:55, Keith Busch a écrit :
> == Changes since v7 ==
>
>   Fixed an early return that prevented reporting HMAT when there are no
>   direct attached initiators.
>
>   Fixed introducing a variable that was unused until several patches
>   later.
>
>   Miscellaneous typos, editorial clarifications, and whitespace fixups.
>
>   Merged to most current linux-next.
>
>   Added received review, test, and ack by's.


Tested-by: Brice Goglin <Brice.Goglin@inria.fr>

I tested this series with several manually-created HMATs.

I already have user-space support in hwloc for reading initiator
symlinks and memory-side cache information.

Looks good.


Given the feedback I sent, patches 06 and 07 even deserve

Reviewed-by: Brice Goglin <Brice.Goglin@inria.fr>

Brice
Keith Busch March 15, 2019, 5:50 p.m. UTC | #2 
Hi Greg,

Just wanted to check with you on how we may proceed with this series.
The main feature is exporting new sysfs attributes through driver core,
so I think it makes most sense to go through you unless you'd prefer
this go through a different route.

The proposed interface has been pretty stable for a while now, and we've
received reviews, acks and tests on all patches. Please let me know if
there is anything else you'd like to see from this series, or if you
just need more time to get around to this.

Thanks,
Keith
Greg Kroah-Hartman March 16, 2019, 3:04 a.m. UTC | #3 
On Fri, Mar 15, 2019 at 11:50:57AM -0600, Keith Busch wrote:
> Hi Greg,
> 
> Just wanted to check with you on how we may proceed with this series.
> The main feature is exporting new sysfs attributes through driver core,
> so I think it makes most sense to go through you unless you'd prefer
> this go through a different route.
> 
> The proposed interface has been pretty stable for a while now, and we've
> received reviews, acks and tests on all patches. Please let me know if
> there is anything else you'd like to see from this series, or if you
> just need more time to get around to this.

I can't do anything with patches until after -rc1 is out, sorry.  Once
that happens I'll work to dig through my pending queue and will review
these then.

thanks,

greg k-h
Greg Kroah-Hartman April 2, 2019, 2:56 p.m. UTC | #4 
On Fri, Mar 15, 2019 at 08:04:07PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Mar 15, 2019 at 11:50:57AM -0600, Keith Busch wrote:
> > Hi Greg,
> > 
> > Just wanted to check with you on how we may proceed with this series.
> > The main feature is exporting new sysfs attributes through driver core,
> > so I think it makes most sense to go through you unless you'd prefer
> > this go through a different route.
> > 
> > The proposed interface has been pretty stable for a while now, and we've
> > received reviews, acks and tests on all patches. Please let me know if
> > there is anything else you'd like to see from this series, or if you
> > just need more time to get around to this.
> 
> I can't do anything with patches until after -rc1 is out, sorry.  Once
> that happens I'll work to dig through my pending queue and will review
> these then.

Sorry for the delay, all now queued up, thanks!

greg k-h