Messages in this thread | | | Date | Wed, 22 Jun 2011 15:47:29 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC][PATCH 2/3] sched, workqueue: Move WQ-sleeper wakeup |
| |
On Wed, 22 Jun 2011, Tejun Heo wrote: > On Wed, Jun 22, 2011 at 01:34:46AM +0200, Peter Zijlstra wrote: > > Preemption could still be enabled here, right? What prevents > preemtion kicking after wq_worker_sleeping() and do it again thus > breaking nr_running tracking.
That wq code should serialize itself and not magically abuse rq->lock for this.
> > * If we are going to sleep and we have plugged IO > > * queued, make sure to submit it to avoid deadlocks. > > */ > > @@ -4256,19 +4235,6 @@ asmlinkage void __sched schedule(void) > > } else { > > deactivate_task(rq, prev, DEQUEUE_SLEEP); > > prev->on_rq = 0; > > - > > - /* > > - * If a worker went to sleep, notify and ask workqueue > > - * whether it wants to wake up a task to maintain > > - * concurrency. > > - */ > > - if (prev->flags & PF_WQ_WORKER) { > > - struct task_struct *to_wakeup; > > - > > - to_wakeup = wq_worker_sleeping(prev, cpu); > > - if (to_wakeup) > > - try_to_wake_up_local(to_wakeup); > > - } > > Similarly, the if the 'if {}' part of the above if/else is taken, the > task never goes to sleep and nr_running will again be broken.
The accounting can be done at schedule entry and exit and not somewhere magic in the wakeup code. It does really not matter, whether nr_running is updated on wakeup or when the worker gets on the cpu.
Thanks,
tglx
| |