From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: <alison.schofield@intel.com>, Ira Weiny <ira.weiny@intel.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
"Ben Widawsky" <bwidawsk@kernel.org>, <linux-cxl@vger.kernel.org>
Subject: Re: [RFC 0/3] Apply SRAT defined PXM to entire CFMWS
Date: Fri, 12 May 2023 17:33:12 +0100 [thread overview]
Message-ID: <20230512173312.00004f11@Huawei.com> (raw)
In-Reply-To: <645d6f5f52ff7_1e6f2942f@dwillia2-xfh.jf.intel.com.notmuch>
On Thu, 11 May 2023 15:42:39 -0700
Dan Williams <dan.j.williams@intel.com> wrote:
> alison.schofield@ wrote:
> > From: Alison Schofield <alison.schofield@intel.com>
> >
> > The patch that created fake NUMA nodes for CFMWS windows
>
> "fake" seems the wrong word to me. These are first class Linux NUMA
> nodes in the end. So to me it's the "patch that extended SRAT proximity
> domains by the potential performance-class windows in the CFMWS", or
> something like that.
>
> > not defined in the SRAT, made wrong assumptions about the
> > SRAT defined entries. Specifically, it assumed an SRAT entry
> > using cfmws->start, uses the entire CMFWS range, start through
> > end. The assumption is wrong, and so the ACPI driver, needs
>
> I also wouldn't say it was wrong, just incomplete. I.e. this is just
> extending the heuristic to say that if the BIOS describes *any* portion
> of a CFMWS window with a proximity domain, might as well reuse that
> proximity domain for the entire window since everything in that window
> is expected to be of a similar performance class.
Some strong assumptions in this statement.
A platform might not care about QTG groups because it's not doing any fancy
QOS stuff (or at least not enough of them to cover 'similar' performance).
At that point, you could have just a few CFMWS with a wide range
of different characteristics. At somepoint I think we'll need to do
something more sophisticated to cover that case. Maybe not yet though.
The moment we have platforms doing interleave or not in the host bridges
we will get very different bandwidth at least, potentially to different
parts of identical memory on the same device. What fun ;)
Jonathan
>
> > to examine the SRAT created memblks more closely to discover
> > partial definitions of the HPA range.
> >
> > This work-in-progress addresses that issue. The first 2 patches
> > introduce numa helpers that are used in the 3rd patch, where the
> > ACPI drivers parsing of the CFMWS is updated.
> >
> > The patch commit logs, especially Patch 3, describes more
> > of the approach as well as other approaches considered, and
> > questions. So, perhaps, scan 1 & 2, and dive into #3 and
> > confirm or refute this approach.
> >
> > I did not include our NUMA or ACPI friends in this posting,
> > because I want to get a direction check from CXL folks before
> > addressing how the helpers can get merged into the NUMA arch.
> >
> > Thanks for looking!
> >
> > Alison Schofield (3):
> > x86/numa: Introduce numa_find_node(start, end)
> > x86/numa: Introduce numa_remove_memblks(node, start, end)
> > ACPI: NUMA: Apply SRAT proximity domain to entire CFMWS window
> >
> > arch/x86/include/asm/numa.h | 2 ++
> > arch/x86/mm/numa.c | 36 ++++++++++++++++++++++++++++++++++++
> > drivers/acpi/numa/srat.c | 32 ++++++++++++++++++++++++++------
> > 3 files changed, 64 insertions(+), 6 deletions(-)
> >
> > --
> > 2.37.3
> >
>
>
prev parent reply other threads:[~2023-05-12 16:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 18:44 [RFC 0/3] Apply SRAT defined PXM to entire CFMWS alison.schofield
2023-05-10 18:44 ` [RFC 1/3] x86/numa: Introduce numa_find_node(start, end) alison.schofield
2023-05-11 22:46 ` Dan Williams
2023-05-10 18:44 ` [RFC 2/3] x86/numa: Introduce numa_remove_memblks(node, start, end) alison.schofield
2023-05-11 22:50 ` Dan Williams
2023-05-10 18:44 ` [RFC 3/3] ACPI: NUMA: Apply SRAT proximity domain to entire CFMWS window alison.schofield
2023-05-11 23:16 ` Dan Williams
2023-05-12 0:01 ` Alison Schofield
2023-05-12 0:18 ` Dan Williams
2023-05-12 16:45 ` Jonathan Cameron
2023-05-11 22:42 ` [RFC 0/3] Apply SRAT defined PXM to entire CFMWS Dan Williams
2023-05-12 16:33 ` Jonathan Cameron [this message]
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=20230512173312.00004f11@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
/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