From: Dan Williams <dan.j.williams@intel.com>
To: Robert Richter <rrichter@amd.com>,
"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>
Cc: Dan Williams <dan.j.williams@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-cxl@vger.kernel.org>, Robert Richter <rrichter@amd.com>,
"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: Tue, 30 Apr 2024 10:05:39 -0700 [thread overview]
Message-ID: <663124e36ecc5_10c21294b6@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <20240430092200.2335887-6-rrichter@amd.com>
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?
next prev parent reply other threads:[~2024-04-30 17:05 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 [this message]
2024-05-02 12:45 ` Robert Richter
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=663124e36ecc5_10c21294b6@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--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=rrichter@amd.com \
--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