On 06.03.2026 15:20, Roger Pau Monné wrote: > On Wed, Nov 12, 2025 at 04:38:13PM +0100, Jan Beulich wrote: >> This NR_CPUS-dimensioned array is likely unused on most installations. >> Therefore it is especially wasteful for it to consume more space than >> really needed. Use the smallest possible type. >> >> Further the array having all fields set to -1 is actually useless. Nothing >> relies on it, and core_parking_remove() doesn't restore the sentinel for >> vacated slots. Drop the initializers, moving the array to .bss. >> >> Finally take the opportunity and update an adjacent variable's type, where >> a fixed-width type was pretty clearly inappropriate to use. >> >> Signed-off-by: Jan Beulich <[email protected]> >> --- >> I assume there is a reason this is acting (mostly) as a LIFO. Else a >> simple cpumask_t would suffice. >> >> An alternative would be to use the new BRK allocator, at least for NR_CPUS >> above a certain threshold. > > Can't we just allocate this memory using xvzalloc_array()? If we do > care about it being too big certainly allocating only when needed, and > based on the number of possible CPUs on the system would be much > better than playing games with the array type?
Hmm, yes, how did it not occur to me to dynamically allocate the array? It can't be used ahead of core_parking_init(). (Not shrinking the array element type will still be a little wasteful, but perhaps that's acceptable to keep the code simple.) Jan
