Re: [PATCH] mm/percpu: account full object size for percpu memory allocations

[Andrew Morton]

On Tue, 13 Oct 2026 23:23:17 +0100 Harry Yoo <harry@xxxxxxxxxx> wrote:

> On Tue, Oct 13, 2026 at 02:54:24PM -0700, Andrew Morton wrote:
> > On Tue, 13 Oct 2026 20:34:39 +0100 "Harry Yoo (Meta)" <harry@xxxxxxxxxx> wrote:
> > 
> > > When memory allocation profiling is enabled, the pages backing percpu
> > > memory chunks are attributed to func:pcpu_alloc_pages. However, the
> > > accounting of individual percpu memory allocations via alloc_percpu()
> > > and friends record only the size of a single object rather than its
> > > full size across all CPUs.
> > > 
> > > As a result, it is often not straightforward to identify which kernel
> > > code is actually responsible for percpu memory, because the size is
> > > under-accounted by a factor of num_possible_cpus().
> > > 
> > > Account full object size with pcpu_obj_full_size(size) instead, which
> > > multiplies the object size by num_possible_cpus() and adds the objcg
> > > pointer overhead. This is consistent with what memcg already does for
> > > charging percpu allocations.
> > > 
> > > Verified with 64-CPU VM by spawning 400 processes in a memory cgroup and
> > > measuring mm_init()'s rss_stat counters.
> > > 
> > > Delta of kernel/fork.c:1142 func:mm_init in /proc/allocinfo:
> > 
> > Please make it use mm_init() rather than func:mm_init.
> 
> This is the output format of /proc/allocinfo:

oh, OK.

> https://docs.kernel.org/filesystems/proc.html#allocinfo
> > Example output.
> > 
> >  > tail -n +3 /proc/allocinfo | sort -rn
> > 127664128    31168 mm/page_ext.c:270 func:alloc_page_ext
> >  56373248     4737 mm/slub.c:2259 func:alloc_slab_page
> >  14880768     3633 mm/readahead.c:247 func:page_cache_ra_unbounded

Well that's odd.  What can a caller be other than a function?

> > 
> > Why cc:stable?
> 
> For anyone who uses memory allocation profiling to understand which
> code locations allocated how much memory, it gives a false impression
> that certain perpcu memory allocations are not as big as they actually
> are.
> 
> On some workloads percpu memory (func:pcpu_alloc_pages) shows up as one
> of the biggest memory allocations, but the actual users of percpu
> memory allocator don't show up as they are under-reported.

OK.  I guess it's a small deal, but a larger deal for allocinfo users!