On Thu, Jun 29, 2017 at 10:40 AM, Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote: > > For all the above, what do you think of my 'sswait' proposal? I see no actual users of such a specialty interface. I don't think we've *ever* had any actual problems with our current wait-queues, apart from the RT issues, which were not about the waitqueues themselves, but purely about RT itself. So without some very compelling reason, I'd not want to add yet another wait-queue. I actually think swait is pure garbage. Most users only wake up one process anyway, and using swait for that is stupid. If you only wake up one, you might as well just have a single process pointer, not a wait list at all, and then use "wake_up_process()". There is *one* single user of swake_up_all(), and that one looks like bogus crap also: it does it outside of the spinlock that could have been used to protect the queue - p,lus I'm not sure there's really a queue anyway, since I think it's just the grace-period kthread that is there. kvm uses swait, but doesn't use swake_up_all(), so it always just wakes up a single waiter. That may be the right thing to do. Or it's just another bug. I don't know. The KVM use looks broken too, since it does if (swait_active(wqp)) { swake_up(wqp); which is racy wrt new waiters, which implies that there is some upper-level synchronization - possibly the same "only one thread anyway". So swake really looks like crap. It has crap semantics, it has crap users, it's just broken. The last thing we want to do is to create something _else_ specialized like this. Linus