lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4b312c8-1117-45cd-a3c3-c8747aca51bd@redhat.com>
Date: Thu, 20 Feb 2025 20:44:36 +0100
From: David Hildenbrand <david@...hat.com>
To: Gregory Price <gourry@...rry.net>
Cc: Yang Shi <shy828301@...il.com>, lsf-pc@...ts.linux-foundation.org,
 linux-mm@...ck.org, linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: CXL Boot to Bash - Section 3: Memory (block) Hotplug

On 20.02.25 20:35, Gregory Price wrote:
> On Thu, Feb 20, 2025 at 08:26:21PM +0100, David Hildenbrand wrote:
>> On 20.02.25 19:43, Gregory Price wrote:
>>
>> There were ideas in how to optimize that (e.g., requiring  a new sysfs
>> interface to expose variable-sized blocks), if anybody is interested, please
>> reach out.
>>
> 
> Multiple block sizes would allow managing the misaligned issues I
> discussed earlier as well (where a memory region is not aligned to the
> arch-preferred block size).  At least in that scenario, the misaligned
> regions could be brought online as minimal block size (256MB) while the
> aligned portions could be brought online in larger (2GB) chunks.
> 
> Do you think this would this require a lot of churn to enable? Last I dug
> through hotplug, it seemed to assume block sizes would be uniform. I was
> hesitant to start ripping through it.

There were some discussions around variable-sized memory blocks. But we 
cannot rip out the old stuff, because it breaks API and thereby Linux 
user space. There would have to be a world switch (e.g., kernel cmdline, 
config option)

... and some corner cases are rather nasty (e.g., hotunplugging boot 
memory, where we only learn from ACPI which regions actually belong to a 
single DIMM; dlpar hotunplugging individual memory blocks of boot memory 
IIRC).

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ