From: Dan Williams <dan.j.williams@intel.com>
To: <alison.schofield@intel.com>,
Dan Williams <dan.j.williams@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>
Cc: Alison Schofield <alison.schofield@intel.com>,
<linux-cxl@vger.kernel.org>
Subject: RE: [RFC 2/3] x86/numa: Introduce numa_remove_memblks(node, start, end)
Date: Thu, 11 May 2023 15:50:54 -0700 [thread overview]
Message-ID: <645d714e62c4e_1e6f29423@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <57bc9bb8823a295dc71d7e8ff8ae93a3af8c0be3.1683742429.git.alison.schofield@intel.com>
alison.schofield@ wrote:
> From: Alison Schofield <alison.schofield@intel.com>
>
> Add support for removing memblks from numa_meminfo that are
> within a start/end range, and of a node.
>
> numa_add_memblk() allows in kernel users to add a memblk to
> a NUMA node. There is no method exposed to remove a memblk.
>
> The use case here is to allow the ACPI driver to remove
> redundant memblks when it knows they exist, rather than
> implementing a cleanup that needlessly walks all memblks
> during a cleanup phase.
Again this assumes a particular way to solve the memblk update problem,
it's not clear that a remove method is the way to go versus an update
method.
I.e. its not clear to me where the "redundant" memblks appear.
> numa_cleanup_meminfo() exists for merging memblks, however,
> it only considers adjacent memblks, and, it actually moves the
> memblks to numa_reserved_meminfo, before doing the cleanup.
So either the algorithm for solving the extend memblks when they overlap
CFMWS needs to be described here, or this patch needs to be squashed.
next prev parent reply other threads:[~2023-05-11 22:51 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 [this message]
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
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=645d714e62c4e_1e6f29423@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--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