From: Robert Richter <rrichter@amd.com>
To: Alison Schofield <alison.schofield@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-cxl@vger.kernel.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v4 6/7] ACPI/NUMA: Add log messages for memory ranges found in CEDT
Date: Fri, 26 Apr 2024 20:14:48 +0200 [thread overview]
Message-ID: <ZivvGJcXKPN_L5fn@rric.localdomain> (raw)
In-Reply-To: <ZiqnbD0CB9WUL1zu@aschofie-mobl2>
On 25.04.24 11:56:44, Alison Schofield wrote:
> On Thu, Apr 25, 2024 at 09:30:15AM +0200, Robert Richter wrote:
> > On 24.04.24 10:54:22, Dan Williams wrote:
> > > Robert Richter wrote:
> > > > Adding a pr_info() when successfully adding a CFMWS memory range.
> > > >
> > > > Suggested-by: Alison Schofield <alison.schofield@intel.com>
> > > > Signed-off-by: Robert Richter <rrichter@amd.com>
> > > > ---
> > > > drivers/acpi/numa/srat.c | 10 +++++++++-
> > > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > > > index e3f26e71637a..c62e4636e472 100644
> > > > --- a/drivers/acpi/numa/srat.c
> > > > +++ b/drivers/acpi/numa/srat.c
> > > > @@ -338,8 +338,11 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > > > * found for any portion of the window to cover the entire
> > > > * window.
> > > > */
> > > > - if (!numa_fill_memblks(start, end))
> > > > + if (!numa_fill_memblks(start, end)) {
> > > > + pr_info("CEDT: memblk extended [mem %#010Lx-%#010Lx]\n",
> > > > + (unsigned long long) start, (unsigned long long) end - 1);
> > >
> > > This looks like pr_debug() material to me.
> >
> > This should have the same log level as the message below and/or its
> > corresponding SRAT message. CEDT mem blocks wouldn't be reported
> > otherwise only because a smaller (overlapping) entry was registered
> > before. That is why I used pr_info here.
>
> It does feel like this message belongs but maybe it should also
> mimic the SRAT define message and emit what node maps this range
> if memblocks were extended.
>
> But...seems this will emit a message for every CFMWS range, even those
> where no memblk needed to be extended - ie the range was fully described
> in the SRAT.
>
> Sadly, numa_fill_memblks() return of 'success' has double meaning.
> It can mean memblks were extended, or that (start, end) was found fully
> described. I don't see an good place to insert the message in
> numa_fill_memblks().
>
> Sorry, just stirring the pot here, with no clear suggestion on how
> to emit info.
Ok, I have changed numa_fill_memblks() to also return if memblks have
been modified. That information is used to print the message.
>
> >
> > >
> > > > return 0;
> > > > + }
> > > >
> > > > /* No SRAT description. Create a new node. */
> > > > node = acpi_map_pxm_to_node(*fake_pxm);
> > > > @@ -354,8 +357,13 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > > > pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
> > > > node, start, end);
> > > > }
> > > > +
> > > > node_set(node, numa_nodes_parsed);
> > > >
> > > > + pr_info("CEDT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
> > > > + node, *fake_pxm,
> > > > + (unsigned long long) start, (unsigned long long) end - 1);
> > > > +
> > >
> > > This makes sense to mirror the SRAT pr_info().
> >
> > I evaluated this.
> >
>
> I read Dan's comment as simple acceptance. Like, yeah this one is good
> because it mimics the SRAT pr_info.
Ah, I misread this, thanks for clarification.
-Robert
next prev parent reply other threads:[~2024-04-26 18:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 15:48 [PATCH v4 0/7] SRAT/CEDT fixes and updates Robert Richter
2024-04-24 15:48 ` [PATCH v4 1/7] x86/numa: Fix SRAT lookup of CFMWS ranges with numa_fill_memblks() Robert Richter
2024-04-24 15:48 ` [PATCH v4 2/7] x86/numa: Remove numa_fill_memblks() from sparsemem.h using __weak Robert Richter
2024-04-24 15:48 ` [PATCH v4 3/7] ACPI/NUMA: Remove architecture dependent remainings Robert Richter
2024-04-24 15:48 ` [PATCH v4 4/7] ACPI/NUMA: Squash acpi_numa_slit_init() into acpi_parse_slit() Robert Richter
2024-04-24 15:48 ` [PATCH v4 5/7] ACPI/NUMA: Squash acpi_numa_memory_affinity_init() into acpi_parse_memory_affinity() Robert Richter
2024-04-24 15:48 ` [PATCH v4 6/7] ACPI/NUMA: Add log messages for memory ranges found in CEDT Robert Richter
2024-04-24 17:54 ` Dan Williams
2024-04-25 7:30 ` Robert Richter
2024-04-25 18:56 ` Alison Schofield
2024-04-26 18:14 ` Robert Richter [this message]
2024-04-24 15:48 ` [PATCH v4 7/7] ACPI/NUMA: Print CXL Early Discovery Table (CEDT) Robert Richter
2024-04-24 17:46 ` [PATCH v4 0/7] SRAT/CEDT fixes and updates Dan Williams
2024-04-25 7:34 ` Robert Richter
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=ZivvGJcXKPN_L5fn@rric.localdomain \
--to=rrichter@amd.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).