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@xxxxxxxxx>
> > > > Signed-off-by: Robert Richter <rrichter@xxxxxxx>
> > > > ---
> > > > 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
