On Sun, 2020-04-19 at 21:17 -0400, Joel Fernandes wrote: > > > > Can we do even better by moving the work-scheduling out from under the > > > spinlock? This of course means that it is necessary to handle the > > > occasional spurious call to the work handler, but that should be rare > > > and should be in the noise compared to the reduction in contention. > > > > Yes I think that will be required since -rt will sleep on workqueue locks as > > well :-(. I'm looking into it right now. > > > > /* > > * If @work was previously on a different pool, it might still be > > * running there, in which case the work needs to be queued on that > > * pool to guarantee non-reentrancy. > > */ > > last_pool = get_work_pool(work); > > if (last_pool && last_pool != pwq->pool) { > > struct worker *worker; > > > > spin_lock(&last_pool->lock); > > Hmm, I think moving schedule_delayed_work() outside lock will work. Just took > a good look and that's not an issue. However calling schedule_delayed_work() > itself is an issue if the caller of kfree_rcu() is !preemptible() on > PREEMPT_RT. Because the schedule_delayed_work() calls spin_lock on pool->lock > which can sleep on PREEMPT_RT :-(. As of 4.19-rt, workqueue locks are converted to raw_spinlock_t. -Mike