On 6/9/22 08:34, Muchun Song wrote:
> On Fri, Apr 29, 2022 at 08:30:44PM +0800, Muchun Song wrote:
>> Most callers of memcg_slab_free_hook() already know the slab, which could
>> be passed to memcg_slab_free_hook() directly to reduce the overhead of an
>> another call of virt_to_slab(). For bulk freeing of objects, the call of
>> slab_objcgs() in the loop in memcg_slab_free_hook() is redundant as well.
>> Rework memcg_slab_free_hook() and build_detached_freelist() to reduce
>> those unnecessary overhead and make memcg_slab_free_hook() can handle bulk
>> freeing in slab_free().
>>
>> Move the calling site of memcg_slab_free_hook() from do_slab_free() to
>> slab_free() for slub to make the code clearer since the logic is weird
>> (e.g. the caller need to judge whether it needs to call
>> memcg_slab_free_hook()). It is easy to make mistakes like missing calling
>> of memcg_slab_free_hook() like fixes of:
>>
>> commit d1b2cf6cb84a ("mm: memcg/slab: uncharge during kmem_cache_free_bulk()")
>> commit ae085d7f9365 ("mm: kfence: fix missing objcg housekeeping for SLAB")
>>
>> This optimization is mainly for bulk objects freeing. The following numbers
>> is shown for 16-object freeing.
>>
>> before after
>> kmem_cache_free_bulk: ~430 ns ~400 ns
>>
>> The overhead is reduced by about 7% for 16-object freeing.
>>
>> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
>
> Hi Vlastimil,
>
> Wolud you mind picking it up? I did not see this patch on the
> slab tree.
Sorry, was waiting for rc1 to start the for-5.20 branches and was away for
another week then. Now pushed to slab/for-5.20/optimizations
> Thanks.
>
