On Wed, 22 May 2024 16:38:01 -0400 Eric Chanudet <echanude@xxxxxxxxxx> wrote:
> x86_64 is already using the node's cpu as maximum threads. Make that the
> default for all archs setting DEFERRED_STRUCT_PAGE_INIT.
>
> This returns to the behavior prior making the function arch-specific
> with commit ecd096506922 ("mm: make deferred init's max threads
> arch-specific").
>
It isn't clear to me what is the runtime effect of this change upon our
users. Can you please prepare a sentence which spells this out?
>
> ---
> Setting DEFERRED_STRUCT_PAGE_INIT and testing on a few arm64 platforms
> shows faster deferred_init_memmap completions:
>
> | | x13s | SA8775p-ride | Ampere R137-P31 | Ampere HR330 |
> | | Metal, 32GB | VM, 36GB | VM, 58GB | Metal, 128GB |
> | | 8cpus | 8cpus | 8cpus | 32cpus |
> |---------|-------------|--------------|-----------------|--------------|
> | threads | ms (%) | ms (%) | ms (%) | ms (%) |
> |---------|-------------|--------------|-----------------|--------------|
> | 1 | 108 (0%) | 72 (0%) | 224 (0%) | 324 (0%) |
> | cpus | 24 (-77%) | 36 (-50%) | 40 (-82%) | 56 (-82%) |
The above is useful info, I'll hoist it into the main changelog.
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -2126,7 +2126,7 @@ deferred_init_memmap_chunk(unsigned long start_pfn, unsigned long end_pfn,
> __weak int __init
> deferred_page_init_max_threads(const struct cpumask *node_cpumask)
> {
> - return 1;
> + return max_t(int, cpumask_weight(node_cpumask), 1);
> }
It's an unrelated cleanup , but that could be
max(cpumask_weight(node_cpumask), 1U);
and the function could/should return unsigned.
