On Tue, 28 Sep 2021 10:44:19 +0200 Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > From: Mike Galbraith <umgwanakikbuti@xxxxxxxxx> > > For efficiency reasons, zsmalloc is using a slim `handle'. The value is > the address of a memory allocation of 4 or 8 bytes depending on the size > of the long data type. The lowest bit in that allocated memory is used > as a bit spin lock. > 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. > > Extend the handle to struct zsmalloc_handle which holds the old handle as > addr and a spinlock_t which replaces the bit spinlock. Replace all the > wrapper functions accordingly. > > The usage of get_cpu_var() in zs_map_object() is problematic because > it disables preemption and makes it impossible to acquire any sleeping > lock on PREEMPT_RT such as a spinlock_t. > Replace the get_cpu_var() usage with a local_lock_t which is embedded > struct mapping_area. It ensures that the access the struct is > synchronized against all users on the same CPU. > > This survived LTP testing. 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? 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?
