[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87jzeegyep.ffs@tglx>
Date: Fri, 11 Oct 2024 22:47:10 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>, LKML
<linux-kernel@...r.kernel.org>
Cc: Waiman Long <longman@...hat.com>
Subject: Re: [patch 20/25] debugobjects: Prepare kmem_cache allocations for
batching
On Thu, Oct 10 2024 at 16:40, Leizhen wrote:
> On 2024/10/8 0:50, Thomas Gleixner wrote:
>> +static bool kmem_alloc_batch(struct hlist_head *head, struct kmem_cache *cache, gfp_t gfp)
>> +{
>> + struct hlist_node *last = NULL;
>> + struct debug_obj *obj;
>> +
>> + for (int cnt = 0; cnt < ODEBUG_BATCH_SIZE; cnt++) {
>> + obj = kmem_cache_zalloc(cache, gfp);
>> + if (!obj) {
>> + free_object_list(head);
>> + return false;
>> + }
>> + debug_objects_allocated++;
>> +
>> + if (!last)
>> + last = &obj->node;
>> + obj->batch_last = last;
>> +
>> + hlist_add_head(&obj->node, head);
>
> There seems to be a need to use hlist_splice_init() outside the loop like patch 2/25.
> Prepare the local list first, if all ODEBUG_BATCH_SIZE is successfully allocated,
> attach it to 'head' at a time, including account debug_objects_allocated. Then back
> to patch 8/25, keep debug_objects_freed still in lock protection and do not move it
> into free_object_list(). Seems like it should be.
In case that the allocation of 16 object fails, the accounting
concurrency problem vs. free_object_list is pretty irrelevant.
It's debug information and moving it under lock protection for a corner
case is just making the code more complex.
Thanks,
tglx
Powered by blists - more mailing lists