Linux CXL
 help / color / mirror / Atom feed
From: Robert Richter <rrichter@amd.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Alison Schofield <alison.schofield@intel.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-cxl@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v6 5/7] ACPI/NUMA: Return memblk modification state from numa_fill_memblks()
Date: Thu, 2 May 2024 14:45:20 +0200	[thread overview]
Message-ID: <ZjOK4Ak1p88Go1hF@rric.localdomain> (raw)
In-Reply-To: <663124e36ecc5_10c21294b6@dwillia2-mobl3.amr.corp.intel.com.notmuch>

On 30.04.24 10:05:39, Dan Williams wrote:
> Robert Richter wrote:
> > When registering a memory range a possibly overlapping memory block
> > will be extended instead of creating a new one. If both ranges exactly
> > overlap, the blocks remain unchanged and are just reused. The
> > information if a memblock was extended is useful for diagnostics.
> 
> What diagnostic flow is this useful for?
> 
> I feel like this post-hoc debug prints for problems we never expect to
> have again, or is there an enduring need for this?

As we are already targeting -rc7, I am going to drop the printout
patches to not block the first patches in this series and will post
them again after the next merge window.

The SRAT logging is very useful to get a picture of the firmware
provided mem blocks. For NUMA debugging these are very helpful, esp.
when working with unmodified generic or distribution kernels. As CFMWS
entries add additional similar information as SRAT, that information
is no longer complete on systems with a CEDT.

The patches just enable the same level of logging for CFMWS as for
SRAT which just adds a single line (info level) per CFMWS entry (in
total just a few). The table printouts are at debug level already. Of
course, there are always other ways to get this information from, but
a grep of dmesg makes things very easy to check things.

Thanks,

-Robert

  reply	other threads:[~2024-05-02 12:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-30  9:21 [PATCH v6 0/7] SRAT/CEDT fixes and updates Robert Richter
2024-04-30  9:21 ` [PATCH v6 1/7] x86/numa: Fix SRAT lookup of CFMWS ranges with numa_fill_memblks() Robert Richter
2024-04-30 14:48   ` Jonathan Cameron
2024-05-02 11:59     ` Robert Richter
2024-05-02 16:27       ` Jonathan Cameron
2024-04-30 16:16   ` Alison Schofield
2024-05-02 12:11     ` Robert Richter
2024-04-30 16:42   ` Dan Williams
2024-04-30  9:21 ` [PATCH v6 2/7] ACPI/NUMA: Remove architecture dependent remainings Robert Richter
2024-04-30 14:53   ` Jonathan Cameron
2024-04-30 16:01   ` Alison Schofield
2024-04-30  9:21 ` [PATCH v6 3/7] ACPI/NUMA: Squash acpi_numa_slit_init() into acpi_parse_slit() Robert Richter
2024-04-30 14:54   ` Jonathan Cameron
2024-04-30 16:01   ` Alison Schofield
2024-04-30  9:21 ` [PATCH v6 4/7] ACPI/NUMA: Squash acpi_numa_memory_affinity_init() into acpi_parse_memory_affinity() Robert Richter
2024-04-30 15:03   ` Jonathan Cameron
2024-04-30 16:01   ` Alison Schofield
2024-04-30  9:21 ` [PATCH v6 5/7] ACPI/NUMA: Return memblk modification state from numa_fill_memblks() Robert Richter
2024-04-30 15:14   ` Jonathan Cameron
2024-04-30 15:49   ` Alison Schofield
2024-04-30 17:05   ` Dan Williams
2024-05-02 12:45     ` Robert Richter [this message]
2024-04-30  9:21 ` [PATCH v6 6/7] ACPI/NUMA: Add log messages for memory ranges found in CEDT Robert Richter
2024-04-30 15:32   ` Jonathan Cameron
2024-04-30 15:49   ` Alison Schofield
2024-04-30 17:14   ` Dan Williams
2024-04-30  9:22 ` [PATCH v6 7/7] ACPI/NUMA: Print CXL Early Discovery Table (CEDT) Robert Richter
2024-04-30 15:55   ` Alison Schofield
2024-04-30 16:22   ` Jonathan Cameron
2024-05-02 12:53     ` 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=ZjOK4Ak1p88Go1hF@rric.localdomain \
    --to=rrichter@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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