On 2024/10/8 0:50, Thomas Gleixner wrote:
> In situations where objects are rapidly allocated from the pool and handed
> back, the size of the per CPU pool turns out to be too small.
>
> Double the size of the per CPU pool.
>
> This reduces the kmem cache allocation and free operations during a kernel compile:
>
> alloc free
> Baseline: 380k 330k
> Double size: 295k 245k
>
> Especially the reduction of allocations is important because that happens
> in the hot path when objects are initialized.
>
> The maximum increase in per CPU pool memory consumption is about 2.5K per
> online CPU, which is acceptable.
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> lib/debugobjects.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -28,7 +28,7 @@
> #define ODEBUG_POOL_SIZE (64 * ODEBUG_BATCH_SIZE)
> #define ODEBUG_POOL_MIN_LEVEL (ODEBUG_POOL_SIZE / 4)
>
> -#define ODEBUG_POOL_PERCPU_SIZE (4 * ODEBUG_BATCH_SIZE)
> +#define ODEBUG_POOL_PERCPU_SIZE (8 * ODEBUG_BATCH_SIZE)
>
> #define ODEBUG_CHUNK_SHIFT PAGE_SHIFT
> #define ODEBUG_CHUNK_SIZE (1 << ODEBUG_CHUNK_SHIFT)
>
> .
>
--
Regards,
Zhen Lei