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
