From: Kai-Heng Feng <kaihengf@nvidia.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Dan Williams <dan.j.williams@intel.com>
Cc: Priya Autee <priya.v.autee@intel.com>, linux-acpi@vger.kernel.org
Subject: Re: [PATCH] ACPI/HMAT: Move HMAT messages to pr_debug()
Date: Wed, 23 Oct 2024 10:02:45 +0800 [thread overview]
Message-ID: <48ee2dde-de1b-4af4-91c8-eebb4e15e191@nvidia.com> (raw)
In-Reply-To: <0ca3dbc4-e791-404c-8058-2b2c24051f5e@nvidia.com>
On 2024/10/7 11:03 AM, Kai-Heng Feng wrote:
> Hi Rafael,
>
> On 2024/1/31 7:54 PM, Rafael J. Wysocki wrote:
>> On Wed, Jan 31, 2024 at 9:30 AM Dan Williams <dan.j.williams@intel.com> wrote:
>>>
>>> The HMAT messages printed at boot, beyond being noisy, can also print
>>> details for nodes that are not yet enabled. The primary method to
>>> consume HMAT details is via sysfs, and the sysfs interface gates what is
>>> emitted by whether the node is online or not. Hide the messages by
>>> default by moving them from "info" to "debug" log level.
>>>
>>> Otherwise, these prints are just a pretty-print way to dump the ACPI
>>> HMAT table. It has always been the case that post-analysis was required
>>> for these messages to map proximity-domains to Linux NUMA nodes, and as
>>> Priya points out that analysis also needs to consider whether the
>>> proximity domain is marked "enabled" in the SRAT.
>>>
>>> Reported-by: Priya Autee <priya.v.autee@intel.com>
>>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> This patch doesn't seem to be included in the tree.
>
> Is it possible to pick this up in the your tree? Thanks!
A gentle ping...
>
> Kai-Heng
>
>>
>>> ---
>>> drivers/acpi/numa/hmat.c | 24 ++++++++++++------------
>>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
>>> index d6b85f0f6082..5331abc7c956 100644
>>> --- a/drivers/acpi/numa/hmat.c
>>> +++ b/drivers/acpi/numa/hmat.c
>>> @@ -409,9 +409,9 @@ static __init int hmat_parse_locality(union
>>> acpi_subtable_headers *header,
>>> return -EINVAL;
>>> }
>>>
>>> - pr_info("Locality: Flags:%02x Type:%s Initiator Domains:%u Target
>>> Domains:%u Base:%lld\n",
>>> - hmat_loc->flags, hmat_data_type(type), ipds, tpds,
>>> - hmat_loc->entry_base_unit);
>>> + pr_debug("Locality: Flags:%02x Type:%s Initiator Domains:%u Target
>>> Domains:%u Base:%lld\n",
>>> + hmat_loc->flags, hmat_data_type(type), ipds, tpds,
>>> + hmat_loc->entry_base_unit);
>>>
>>> inits = (u32 *)(hmat_loc + 1);
>>> targs = inits + ipds;
>>> @@ -422,9 +422,9 @@ static __init int hmat_parse_locality(union
>>> acpi_subtable_headers *header,
>>> value = hmat_normalize(entries[init * tpds + targ],
>>> hmat_loc->entry_base_unit,
>>> type);
>>> - pr_info(" Initiator-Target[%u-%u]:%u%s\n",
>>> - inits[init], targs[targ], value,
>>> - hmat_data_type_suffix(type));
>>> + pr_debug(" Initiator-Target[%u-%u]:%u%s\n",
>>> + inits[init], targs[targ], value,
>>> + hmat_data_type_suffix(type));
>>>
>>> hmat_update_target(targs[targ], inits[init],
>>> mem_hier, type, value);
>>> @@ -452,9 +452,9 @@ static __init int hmat_parse_cache(union
>>> acpi_subtable_headers *header,
>>> }
>>>
>>> attrs = cache->cache_attributes;
>>> - pr_info("Cache: Domain:%u Size:%llu Attrs:%08x SMBIOS Handles:%d\n",
>>> - cache->memory_PD, cache->cache_size, attrs,
>>> - cache->number_of_SMBIOShandles);
>>> + pr_debug("Cache: Domain:%u Size:%llu Attrs:%08x SMBIOS Handles:%d\n",
>>> + cache->memory_PD, cache->cache_size, attrs,
>>> + cache->number_of_SMBIOShandles);
>>>
>>> target = find_mem_target(cache->memory_PD);
>>> if (!target)
>>> @@ -513,9 +513,9 @@ static int __init hmat_parse_proximity_domain(union
>>> acpi_subtable_headers *heade
>>> }
>>>
>>> if (hmat_revision == 1)
>>> - pr_info("Memory (%#llx length %#llx) Flags:%04x Processor
>>> Domain:%u Memory Domain:%u\n",
>>> - p->reserved3, p->reserved4, p->flags, p->processor_PD,
>>> - p->memory_PD);
>>> + pr_debug("Memory (%#llx length %#llx) Flags:%04x Processor
>>> Domain:%u Memory Domain:%u\n",
>>> + p->reserved3, p->reserved4, p->flags, p->processor_PD,
>>> + p->memory_PD);
>>> else
>>> pr_info("Memory Flags:%04x Processor Domain:%u Memory
>>> Domain:%u\n",
>>> p->flags, p->processor_PD, p->memory_PD);
>>>
>
next prev parent reply other threads:[~2024-10-23 2:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 8:30 [PATCH] ACPI/HMAT: Move HMAT messages to pr_debug() Dan Williams
2024-01-31 11:54 ` Rafael J. Wysocki
2024-10-07 3:03 ` Kai-Heng Feng
2024-10-23 2:02 ` Kai-Heng Feng [this message]
2024-12-04 2:51 ` Kai-Heng Feng
2024-12-04 20:09 ` Dan Williams
2024-12-04 20:55 ` Dave Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48ee2dde-de1b-4af4-91c8-eebb4e15e191@nvidia.com \
--to=kaihengf@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=priya.v.autee@intel.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox