On Tue, Feb 04, 2020 at 02:21:02PM +0100, Martin Pieuchot wrote: > As recently profiled, the softnet thread which runs mostly without > KERNEL_LOCK() is still somehow serialized with the rest of the kernel. > This is because the various subsystems to notify userland, either via > poll(2)/select(2), kqueue(2) or pgsignal(9) still require this lock. > > We worked around this in bpf(4) by deferring the notification. However > such approach isn't trivially applied everywhere and doesn't help with > getting the subsystems out of the KERNEL_LOCK(). > > Thanks to many people working on MP, the kernel now has multiple consumers > of the notification hooks that can be used to test & expose possible bugs > related to the removal of the KERNEL_LOCK() in these areas. > > Diff below takes the first step of pushing the KERNEL_LOCK() in the > subsystems. That means the lock might be taken & released twice if an > application asked for being notified via signal and via poll/kevent.
I think this is fine. Use of signal-based notification is quite unusual in modern software, and use of both signals and poll/kevent with the same file is all the more so. > It is unclear to me if this change of behavior degrades latency in a > noticeable way. If it does and people report it, we should consider > keeping a single KERNEL_LOCK/UNLOCK() dance in the affected subsystem. > > Comments? Oks? OK visa@
