[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o75583nv.ffs@tglx>
Date: Tue, 03 Sep 2024 11:52:52 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Zhen Lei <thunder.leizhen@...wei.com>, Andrew Morton
<akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org
Cc: Zhen Lei <thunder.leizhen@...wei.com>
Subject: Re: [PATCH 3/5] debugobjects: Don't start fill if there are
remaining nodes locally
On Mon, Sep 02 2024 at 22:05, Zhen Lei wrote:
> If the conditions for starting fill are met, it means that all cores that
> call fill() later are blocked until the first core completes the fill
> operation. But obviously, for a core that has free nodes locally, it does
> not need to be blocked. This is good in stress situations.
Sure it's good, but is it correct? You need to explain why this can't
cause a pool depletion. The pool is filled opportunistically.
Aside of that the lock contention in fill_pool() is minimal. The heavy
lifting is the allocation of objects.
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index aba3e62a4315f51..fc8224f9f0eda8f 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -130,10 +130,15 @@ static void fill_pool(void)
> gfp_t gfp = __GFP_HIGH | __GFP_NOWARN;
> struct debug_obj *obj;
> unsigned long flags;
> + struct debug_percpu_free *percpu_pool;
Please keep variables in reverse fir tree order.
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#variable-declarations
> if (likely(READ_ONCE(obj_pool_free) >= debug_objects_pool_min_level))
> return;
>
> + percpu_pool = this_cpu_ptr(&percpu_obj_pool);
You don't need the pointer
> + if (likely(obj_cache) && percpu_pool->obj_free > 0)
if (likely(obj_cache) && this_cpu_read(percpu_pool.obj_free) > 0)
This lacks a comment explaining the rationale of this check.
Thanks,
tglx
Powered by blists - more mailing lists