From: David Hildenbrand <david@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>,
Gregory Price <gourry@gourry.net>,
Ira Weiny <ira.weiny@intel.com>
Cc: linux-cxl@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, osalvador@suse.de,
gregkh@linuxfoundation.org, rafael@kernel.org,
akpm@linux-foundation.org, Jonathan.Cameron@huawei.com,
alison.schofield@intel.com, rrichter@amd.com,
terry.bowman@amd.com, lenb@kernel.org, dave.jiang@intel.com
Subject: Re: [PATCH 3/3] acpi,srat: reduce memory block size if CFMWS has a smaller alignment
Date: Mon, 14 Oct 2024 13:50:04 +0200 [thread overview]
Message-ID: <1791f0e4-1c4e-41cd-b34b-cf63dedec912@redhat.com> (raw)
In-Reply-To: <670561ebe74b7_964fe29460@dwillia2-xfh.jf.intel.com.notmuch>
On 08.10.24 18:46, Dan Williams wrote:
> Gregory Price wrote:
>> On Tue, Oct 08, 2024 at 09:58:35AM -0500, Ira Weiny wrote:
>>> Gregory Price wrote:
>>>> The CXL Fixed Memory Window allows for memory aligned down to the
>>>> size of 256MB. However, by default on x86, memory blocks increase
>>>> in size as total System RAM capacity increases. On x86, this caps
>>>> out at 2G when 64GB of System RAM is reached.
>>>>
>>>> When the CFMWS regions are not aligned to memory block size, this
>>>> results in lost capacity on either side of the alignment.
>>>>
>>>> Parse all CFMWS to detect the largest common denomenator among all
>>>> regions, and reduce the block size accordingly.
>>>>
>>>> This can only be done when MEMORY_HOTPLUG and SPARSEMEM configs are
>>>> enabled, but the surrounding code may not necessarily require these
>>>> configs, so build accordingly.
>>>>
>>>> Suggested-by: Dan Williams <dan.j.williams@intel.com>
>>>> Signed-off-by: Gregory Price <gourry@gourry.net>
>>>> ---
> [..]
>>> To help address David's comment as well;
>>>
>>> Is there a way to scan all the alignments of the windows and pass the
>>> desired alignment to the arch in a new call and have the arch determine if
>>> changing the order is ok?
>>>
>>
>> At least on x86, it's only OK during init, so it would probably look like
>> setting a static bit (like the global value in x86) and just refusing to
>> update once it is locked.
>>
>> I could implement that on the x86 side as an example.
>>
>> FWIW: this was Dan's suggestion (quoting discord, sorry Dan!)
>> ```
>> I am assuming we would call it here
>> drivers/acpi/numa/srat.c::acpi_parse_cfmws()
>> which should be before page-allocator init
>> ```
>>
>> It's only safe before page-allocator init (i.e. once blocks start getting
>> populated and used), and this area occurs before that.
Sorry for the late reply. It must also be called before
memory_dev_init(), which happens after the buddy is up IIRC.
>
> I will note though that drivers/acpi/numa/srat.c is always built-in, so
> there is no need for set_memory_block_size_order() to be EXPORT_SYMBOL
> for modules to play with, just an extern for NUMA init to access.
That's the magic piece I was missing.
Because it didn't make too much sense for me a call to this function
would ever makes sense after modules where loaded.
This really only works that early during boot, that modules are not
loaded yet.
So this patch here should be dropped.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-10-14 11:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 4:43 [PATCH 0/3] memory,acpi: resize memory blocks based on CFMW alignment Gregory Price
2024-10-08 4:43 ` [PATCH 1/3] memory: extern memory_block_size_bytes and set_memory_block_size_order Gregory Price
2024-10-08 14:03 ` David Hildenbrand
2024-10-08 14:51 ` Gregory Price
2024-10-08 15:02 ` David Hildenbrand
2024-10-08 15:21 ` Gregory Price
2024-10-08 19:04 ` Ira Weiny
2024-10-08 19:45 ` Gregory Price
2024-10-14 11:54 ` David Hildenbrand
2024-10-14 14:25 ` Gregory Price
2024-10-14 20:32 ` David Hildenbrand
2024-10-14 22:40 ` Gregory Price
2024-10-08 4:43 ` [PATCH 2/3] x86/mm: if memblock size is adjusted, update the cached value Gregory Price
2024-10-08 4:43 ` [PATCH 3/3] acpi,srat: reduce memory block size if CFMWS has a smaller alignment Gregory Price
2024-10-08 14:58 ` Ira Weiny
2024-10-08 15:17 ` Gregory Price
2024-10-08 16:46 ` Dan Williams
2024-10-14 11:50 ` David Hildenbrand [this message]
2024-10-08 19:02 ` Ira Weiny
2024-10-08 14:38 ` [PATCH 0/3] memory,acpi: resize memory blocks based on CFMW alignment Ira Weiny
2024-10-08 14:49 ` Gregory Price
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=1791f0e4-1c4e-41cd-b34b-cf63dedec912@redhat.com \
--to=david@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=osalvador@suse.de \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@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;
as well as URLs for NNTP newsgroup(s).