On Fri, Mar 21, 2025 at 02:07:31PM -0400, Gregory Price wrote: > Device capacity intended for use as system ram should be aligned to the > architecture-defined memory block size or that capacity will be silently > truncated and capacity stranded. > > As hotplug dax memory becomes more prevelant, the memory block size > alignment becomes more important for platform and device vendors to > pay attention to - so this truncation should not be silent. > > This issue is particularly relevant for CXL Dynamic Capacity devices, > whose capacity may arrive in spec-aligned but block-misaligned chunks. > > Example: > [...] kmem dax0.0: dax region truncated 2684354560 bytes - alignment > [...] kmem dax1.0: dax region truncated 1610612736 bytes - alignment > > Signed-off-by: Gregory Price <gou...@gourry.net>
Gentle pokes. There were a couple questions last week whether we should warn here or actually fix something in memory-hotplug. Notes from CXL Boot to Bash session discussions: We discussed [1] how this auto-sizing can cause 1GB huge page allocation failures (assuming you online as ZONE_NORMAL). That means ACPI-informed sizing by default would potentially be harmful to existing systems and adding yet-another-boot-option just seems nasty. I've since dropped acpi-informed block size patch[2]. If there are opinions otherwise, I can continue pushing it. We also discussed[3] variable-sized blocks having some nasty corner cases. Not unsolvable, but doesn't help users in the short term. There was some brief discussion about whether a hotplug memblock with a portion as offline pages would be possible. This seems hacky? There was another patch set discussing this, but I can't seem to find it. I debated whether to warn here or in ACPI. This seemed more accurate, as platforms could simply over-reserve HPA space to avoid the issue. Thoughts? ~Gregory [1] https://lore.kernel.org/all/bda4cf52-d81a-4935-b45a-09e9439e3...@redhat.com/ [2] https://lore.kernel.org/linux-mm/20250127153405.3379117-1-gou...@gourry.net/ [3]https://lore.kernel.org/all/b4b312c8-1117-45cd-a3c3-c8747aca5...@redhat.com/
