Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 25 May 2022 18:29:14 +0800
From:   Muchun Song <songmuchun@bytedance.com>
To:     Vlastimil Babka <vbabka@suse.cz>
Cc:     cl@linux.com, penberg@kernel.org, rientjes@google.com,
        iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
        roman.gushchin@linux.dev, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, smuchun@gmail.com
Subject: Re: [PATCH v2] mm: slab: optimize memcg_slab_free_hook()
Message-ID: <Yo4E+mk3/XlQJ6Pw@FVFYT0MHHV2J.usts.net>
References: <20220429123044.37885-1-songmuchun@bytedance.com>
 <86fdbde5-a010-9473-2f5d-807c86620509@suse.cz>
 <Yo2R3VA1LIwx10FM@FVFYT0MHHV2J.googleapis.com>
 <b34a75ac-389a-3965-9c56-0b18adc8440d@suse.cz>
 <Yo3zmQLzHqdeyr3V@FVFYT0MHHV2J.googleapis.com>
 <970bbb88-3fc7-d2b9-6bb5-9c315888a889@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <970bbb88-3fc7-d2b9-6bb5-9c315888a889@suse.cz>
Precedence: bulk

On Wed, May 25, 2022 at 12:09:19PM +0200, Vlastimil Babka wrote:
> On 5/25/22 11:15, Muchun Song wrote:
> > On Wed, May 25, 2022 at 09:34:58AM +0200, Vlastimil Babka wrote:
> >> On 5/25/22 04:18, Muchun Song wrote:
> >> > On Tue, May 24, 2022 at 07:05:31PM +0200, Vlastimil Babka wrote:
> >> >> On 4/29/22 14:30, 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")
> >> >> 
> >> >> Hm is this commit also fixing such bug? in mm/slab.c __cache_free():
> >> >>
> > 
> > Sorry, I think I have misread it and misled you here.  I mean commit
> 
> My bad, I should have said "this patch" referring to yours, not "this
> commit" which could refer to ae085d7f9365.
> 
> > ae085d7f9365 ("mm: kfence: fix missing objcg housekeeping for SLAB")
> > is a bug fix, this commit does not fix any issue since __cache_free()
> > will be called from qlink_free() and __cache_free() will call
> > memcg_slab_free_hook(), so there is no issues.  This commit is totally
> > an improvements for memcg_slab_free_hook().
> 
> Ah, I see, indeed. The un-quarantining in kasan went through
> memcg_slab_free_hook() before your patch. But yeah it's better to do it
> earlier as the freed object's user is who charged it to the memcg, and is no
> longer using it - no reason to keep it accounted while in kasan's quarantine.
>

I couldn't agree more.

Thanks.