On April 19, 2020 11:02:41 PM EDT, Mike Galbraith <efault@xxxxxx> wrote:
>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.
>
Thanks for the clarification on that!!
- Joel
> -Mike
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
