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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <877cd3u1go.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Tue, 30 Jul 2024 09:12:55 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org,  akpm@...ux-foundation.org,  dave.jiang@...el.com,
  Jonathan.Cameron@...wei.com,  horenchuang@...edance.com,
  linux-kernel@...r.kernel.org,  linux-acpi@...r.kernel.org,
  dan.j.williams@...el.com,  lenb@...nel.org, Aneesh Kumar K.V
 <aneesh.kumar@...ux.ibm.com>
Subject: Re: [PATCH] acpi/hmat,mm/memtier: always register hmat adist
 calculation callback

Gregory Price <gourry@...rry.net> writes:

> On Mon, Jul 29, 2024 at 09:02:33AM +0800, Huang, Ying wrote:
>> Gregory Price <gourry@...rry.net> 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.

IIUC, HMAT is optional.  Is it possible for you to ask the system vendor
to fix the broken HMAT table.

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

I don't think so, in drivers/dax/kmem.c, we will put memory devices
onlined by kmem.c in another tier by default.

> 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.

If HMAT isn't available, it's hard to put memory devices to
appropriate memory tiers without other information.  In commit
992bf77591cb ("mm/demotion: add support for explicit memory tiers"),
Aneesh pointed out that it doesn't work for his system to put
non-CPU-nodes in lower tier.

Even if we want to use other information to put memory devices to memory
tiers, we can register another adist calculation callback instead of
reusing hmat callback.

--
Best Regards,
Huang, Ying