Re: [PATCH v5 2/4] mm/zsmalloc: drop pool->lock from zs_free on 64-bit systems

[Barry Song]

On Wed, Jun 24, 2026 at 2:15 PM Wenchao Hao <haowenchao22@xxxxxxxxx> wrote:
>
> On Tue, Jun 23, 2026 at 7:15 AM Barry Song <baohua@xxxxxxxxxx> wrote:
> >
> > On Tue, Jun 16, 2026 at 11:13 AM Wenchao Hao <haowenchao22@xxxxxxxxx> wrote:
> > >
> > > From: Wenchao Hao <haowenchao@xxxxxxxxxx>
> > >
> > > With class_idx encoded in obj, zs_free() can locate the size_class
> > > without holding pool->lock on 64-bit systems.  Page migration also
> > > takes class->lock and only rewrites the PFN field of obj, so:
> > >
> > >   1. read obj locklessly,
> > >   2. lock the size_class derived from obj's class_idx,
> > >   3. re-read obj under class->lock to get a stable PFN.
> > >
> > > This eliminates the rwlock read-side cacheline bouncing between
> > > zs_free() and migration/compaction on multi-core systems.
> > >
> > > Annotate handle_to_obj()/record_obj() with READ_ONCE()/WRITE_ONCE() to
> > > prevent load/store tearing on the lockless read path and silence KCSAN
> > > data race reports.
> > >
> > > When ZS_OBJ_CLASS_BITS == 0 (32-bit, or 64-bit with obj too narrow to
> > > hold class_idx), zs_free() keeps pool->lock.
> > >
> > > Reviewed-by: Nhat Pham <nphamcs@xxxxxxxxx>
> > > Signed-off-by: Wenchao Hao <haowenchao@xxxxxxxxxx>
> >
> > Reviewed-: Barry Song <baohua@xxxxxxxxxx>
> >
> > [...]
> > > +static inline void obj_handle_class_lock(struct zs_pool *pool, unsigned long handle,
> > > +                                        unsigned long *objp, struct zspage **zspagep,
> > > +                                        struct size_class **classp)
> > > +       __acquires(&(*classp)->lock)
> > > +{
> >
> >
> > Somehow, I feel that obj_handle_class_lock() is a misleading name.
> > The function clearly does more than just handle class locking—it also
> > retrieves the object and the zspage.
> >
>
> Thanks for the suggestion. How about obj_to_class_and_lock()?
>
> This name reflects the two key things the function does:
> 1. Resolves obj -> class (via class_idx or zspage, depending on arch)
> 2. Acquires and holds class->lock on return
>
> The "to_class" part captures the lookup/resolution, and "and_lock"
> makes the locking responsibility explicit.

I think obj_to_class_and_lock() is not a good fit.

The issue is that class is a noun, while lock is a verb, so the
name mixes a transformation (obj_to_class) with an action
(and_lock) in an inconsistent way. It reads asymmetrically.

maybe just your original name if we can't find a better one:-)

There are only two hard things in Computer Science: cache
invalidation and naming things.

Best Regards
Barry