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… > Which is identical to asking "what is the impact of switching to the new > scheme for PREEMPT_RT"! Which is I think an important thing for the > changelog to address? Well, PREEMPT_RT can't work with the bit spinlock in it. That is that part from the changelog: | The usage of the bit spin lock is problematic because with the bit spin | lock held zsmalloc acquires a rwlock_t and spinlock_t which are both | sleeping locks on PREEMPT_RT and therefore must not be acquired with | disabled preemption. Sebastian
