On Wed, Sep 29, 2021 at 09:23:59AM +0200, Sebastian Andrzej Siewior wrote: > On 2021-09-28 15:47:23 [-0700], Andrew Morton wrote: > > Rather nasty with all the ifdefs and two different locking approaches > > to be tested. What would be the impact of simply switching to the new > > scheme for all configs? > > The current scheme uses the lower bit (OBJ_ALLOCATED_TAG) as something > special which is guaranteed to be zero due to memory alignment > requirements. The content of the memory, that long, is then used a bit > spinlock. > > Moving it to spinlock_t would consume only 4 bytes of memory assuming > lockdep is off. It is then 4 bytes less than a long on 64 bits archs. > So we could do this if nobody disagrees. The spinlock_t has clearly > advantages over a bit spinlock like the "order" from the qspinlock > implementation. But then I have no idea what the contention here is. > With lockdep enabled the struct gets a little bigger which I assume was to > avoid. But then only debug builds are affected so… First of all, thanks for the patch, Sebastian. The zsmalloc is usually used with swap and swap size is normally several GB above. Thus, adding per-page spinlock is rather expensive so I'd like to consider the approach as last resort. About the lock contention, it's rare so spinlock wouldn't help it much. Let me try changing the bit lock into sleepable lock in PREEMPT_RT with bigger granuarity.
