Re: [PATCH] acpi/hmat,mm/memtier: always register hmat adist calculation callback

[Gregory Price]

On Mon, Jul 29, 2024 at 09:02:33AM +0800, Huang, Ying wrote:
> Gregory Price <gourry@xxxxxxxxxx> writes:
> 
> > In the event that hmat data is not available for the DRAM tier,
> > or if it is invalid (bandwidth or latency is 0), we can still register
> > a callback to calculate the abstract distance for non-cpu nodes
> > and simply assign it a different tier manually.
> >
> > In the case where DRAM HMAT values are missing or not sane we
> > manually assign adist=(MEMTIER_ADISTANCE_DRAM + MEMTIER_CHUNK_SIZE).
> >
> > If the HMAT data for the non-cpu tier is invalid (e.g. bw = 0), we
> > cannot reasonable determine where to place the tier, so it will default
> > to MEMTIER_ADISTANCE_DRAM (which is the existing behavior).
> 
> Why do we need this?  Do you have machines with broken HMAT table?  Can
> you ask the vendor to fix the HMAT table?
>

It's a little unclear from the ACPI specification whether HMAT is
technically optional or not (given that the kernel handles missing HMAT
gracefully, it certainly seems optional). In one scenario I have seen
incorrect data, and in another scenario I have seen the HMAT omitted
entirely. In another scenario I have seen the HMAT-SLLBI omitted while
the CDAT is present.

In all scenarios the result is the same: all nodes in the same tier.


The HMAT is explicitly described as "A hint" in the ACPI spec.

ACPI 5.2.28.1 HMAT Overview

"The software is expected to use this information as a hint for
optimization, or when the system has heterogeneous memory"

If something is "a hint", then it should not be used prescriptively.

Right now HMAT appears to be used prescriptively, this despite the fact
that there was a clear intent to separate CPU-nodes and non-CPU-nodes in
the memory-tier code. So this patch simply realizes this intent when the
hints are not very reasonable.

~Gregory