Re: [PATCH] mm/percpu: allow embed allocator when total size fits in vmalloc

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 17 Jul 2026 16:16:16 -0700 Paul Sherman <shermanpauldylan@gmail.com> wrote:

> On large NUMA systems (e.g. 4-node 128GB), the physical span between
> NUMA nodes may exceed 75% of vmalloc space even though the total percpu
> allocation is tiny (e.g. ~6MB for 64 CPUs).
> 
> The 75% check was designed for pcpu_get_vm_areas() used by dynamic
> percpu chunks, where vmalloc congruency is required. The embed
> allocator uses the linear map directly for the first chunk -- physical
> addresses are accessible as virtual addresses without vmalloc mapping.
> The relevant constraint is total percpu size, not physical span.
> 
> Replace the unconditional fallback with a total-size check: if the
> aggregate percpu allocation fits within 75% of vmalloc space, proceed
> with embed regardless of physical NUMA span. Systems where total percpu
> size genuinely exceeds the vmalloc bound retain the page allocator
> fallback.
> 
> Tested on Sophgo SG2042 (64-hart, 4-NUMA, 128GB DDR4, RISC-V Sv39):
>   percpu: embed: span 0x17def7a000 > vmalloc 75% but total 0x5c0000
>           fits -- linear map used
>   percpu: Embedded 23 pages/cpu s54168 r8192 d31848 u94208

Nicely presented patch, thanks.

> Link: https://lkml.iu.edu/hypermail/linux/kernel/1707.3/00337.html
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Dennis Zhou <dennis@kernel.org>
> Signed-off-by: Paul Sherman <shermanpauldylan@gmail.com>
> ---
> 
> This fix is inert on systems where the original check never fired;
> it only activates when physical span exceeds 75% of vmalloc but total
> percpu size does not.
> 
> Architecture analysis:
> 
>   Architecture   | vmalloc      | phys span    | total percpu | result
>   ---------------|--------------|--------------|--------------|--------
>   RISC-V Sv39    | ~88 GB       | ~102 GB      | ~6 MB        | fixed
>   RISC-V Sv48    | ~88 TB       | ~102 GB      | ~6 MB        | unaffected
>   RISC-V Sv57    | ~44 PB       | ~102 GB      | ~6 MB        | unaffected
>   ARM64 large    | ~248 TB      | varies       | tiny         | unaffected
>   32-bit NUMA    | ~128 MB      | varies       | may exceed   | correct fallback
> 
> Tejun Heo noted in 2017 [Link] that the only constraint is vmalloc
> size relative to NUMA node distances, and that making vmalloc bigger
> would be the best fix. On RISC-V Sv39 with 88GB vmalloc and 102GB
> physical NUMA span that is not an option -- but the embed allocator
> does not need congruent vmalloc mapping for the first chunk anyway.

I suggest all the above be moved above the "---" separator.  It's
useful info for the permanent record.  (And replace "[Link]" with "[1]"
in the usual fashion).

>  mm/percpu.c | 29 ++++++++++++++++++++++++-----
>  1 file changed, 24 insertions(+), 5 deletions(-)

AI review asked a question:
	https://sashiko.dev/#/patchset/20260717231616.9126-1-shermanpauldylan@gmail.com