Re: [PATCH] mm: percpu: Increase PERCPU_MODULE_RESERVE

[Tejun Heo <tj@kernel.org>]

On Wed, Jun 11, 2025 at 08:32:57PM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-06-11 07:45:46 [-1000], Tejun Heo wrote:
> > On Wed, Jun 11, 2025 at 06:18:49PM +0200, Sebastian Andrzej Siewior wrote:
> > > PERCPU_MODULE_RESERVE defines the maximum size that can by used for the
> > > per-CPU data size used by modules. This is 8KiB.
> > > 
> > > Commit 035fcdc4d240c ("openvswitch: Merge three per-CPU structures into
> > > one") restructured the per-CPU memory allocation for openvswitch and
> > > moved the separate alloc_percpu() invocations at module init time to a
> > > static per-CPU variable which is allocated by the module loader.
> > > 
> > > The size of the per-CPU data section for openvswitch is 6488 bytes which
> > > is ~80% of the available per-CPU memory. Together with a few other
> > > modules it is easy to exhaust the available 8KiB of memory.
> > > 
> > > The memory range for the per-CPU memory is allocated early and pages for
> > > its backing are only allocated once the per-CPU memory is allocated.
> > > Increasing the map from 8 to 16 KiB adds 256 bytes to the alloc_map and
> > > bound_map and 64 bytes to md_blocks (576 bytes in total).
> > > 
> > > Increase the available memory for module's per-CPU data section to
> > > 16KiB.
> > 
> > I think a better direction would be keeping using alloc_percpu(). There
> > aren't a lot of benefits to using static definitions compared to dynamic
> > ones and making it larger increases overhead for everyone.
> 
> I could avoid initialising per-CPU locks because of the static build
> time init and avoid the alloc_percpu() at module init. I can access
> members of the struct avoid one pointer dereference. All this for 576
> bytes.

Yeah but for that, you're making all machines that run the kernel to waste
two more pages per CPU. Modern machines are big and the overhead quickly
gets into megs. Sure, it's not a huge amount of memory but it's going to be
memory that almost nobody uses, relatively speaking, which just sits there
and gets wasted.

Thanks.

-- 
tejun