Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1371910
| From | luca abeni <luca.abeni@unitn.it> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC v2 3/7] Improve the tracking of active utilisation |
| Date | 2016-04-05 21:40 +0200 |
| Message-ID | <rkEZs-vr-27@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <rj9bl-6jH-31@gated-at.bofh.it> <rkAMb-5KI-29@gated-at.bofh.it> <rkDqG-7Lp-15@gated-at.bofh.it> <rkDAm-864-9@gated-at.bofh.it> <rkEPM-qh-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, 5 Apr 2016 21:24:24 +0200 luca abeni <luca.abeni@unitn.it> wrote: > On Tue, 5 Apr 2016 20:02:52 +0200 > Peter Zijlstra <peterz@infradead.org> wrote: > > > On Tue, Apr 05, 2016 at 07:56:57PM +0200, luca abeni wrote: > > > > > > > + migrate_active = hrtimer_active(&p->dl.inactive_timer); > > > > > + if (migrate_active) > > > > > + sub_running_bw(&p->dl, &rq->dl); > > > > > + raw_spin_unlock(&rq->lock); > > > > > > > > At this point task_rq() is still the above rq, so if the inactive timer > > > > hits here it will lock this rq and subtract the running bw here _again_, > > > > right? > > > I think it will see the task state as TASK_RUNNING, so it will do nothing. > > > Or it will cancelled later when the task is enqueued... I'll double check this. > > > > Right, so this is select_task_rq_dl(), we run this in wakeups, before > > TASK_RUNNING. > > Sigh... I knew I was missing something here... :( > So, I think the solution here is to use double_lock_balance() (or something > like that) to take both the rq locks so that the inactive timer handler cannot > run between sub_running_bw() and add_running_bw()... I'll try this. Double thinking about this: isn't p->pi_lock saving us here? I mean: - try_to_wake_up() takes p->pi_lock before doing anything else - so, select_task_rq() is invoked with p->pi_lock locked - but inactive_task_timer() does "rq = task_rq_lock(p, &flags)", and task_rq_lock() tries to take p->pi_lock - so, we should be safe, no? Maybe this is why I never managed to trigger this race... :) Thanks, Luca
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC v2 3/7] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-04-05 17:10 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation luca abeni <luca.abeni@unitn.it> - 2016-04-05 20:00 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-04-05 20:10 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation luca abeni <luca.abeni@unitn.it> - 2016-04-05 21:30 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-04-05 21:40 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation luca abeni <luca.abeni@unitn.it> - 2016-04-05 21:40 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-04-05 20:10 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation luca abeni <luca.abeni@unitn.it> - 2016-04-05 21:40 +0200
Re: [RFC v2 3/7] Improve the tracking of active utilisation Peter Zijlstra <peterz@infradead.org> - 2016-04-05 20:20 +0200
csiph-web