Re: [PATCH 8/8] zsmalloc: replace get_cpu_var with local_lock

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2021-11-14 19:56:47 [-0800], Davidlohr Bueso wrote:
> ... or flat-out migrate_disabling when the per-CPU data structure already
> has a spinlock it acquires anyway, which will do the serialization:
> 
> 5. vmalloc. Since we already have a vmap_block_queue.lock
> 
> 6. sunrpc. Since we already have a pool->sp_lock.
> 
> I've got patches for these but perhaps I'm missing a fundamental reason as
> to why these are still out-of-tree and get_cpu()-light family is still around.
> For example, direct migrate_disable() calls are frowned upon and could well
> be unacceptable - albeit it's recent user growth upstream.
> 
> Thoughts?

I think tglx is looking into this to get it done differently. We had a
few more users of get_cpu_light() and we got rid of a few of them. We
also had more local_lock() users but we got rid of all but two I think
before local_lock() was suggested upstream.
From RT's point of view, get_cpu() and get_cpu_var() leads almost always
to trouble. The vmalloc example from above, I don't think there is need
for get_cpu() or migrate_disable() or anything at all because the
per-CPU data structure itself is locked. The window of possible CPU
migration is little so even if it happens, the result is correct.

> Thanks,
> Davidlohr

Sebastian