Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495758
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI |
| Date | 2016-10-05 10:40 +0200 |
| Message-ID | <soPU5-6MT-7@gated-at.bofh.it> (permalink) |
| References | <so7Jo-32K-13@gated-at.bofh.it> <so7Jo-32K-15@gated-at.bofh.it> <soP7I-6bh-17@gated-at.bofh.it> <soPr4-6yF-11@gated-at.bofh.it> <soPKp-6Jj-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Oct 05, 2016 at 10:21:02AM +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-05 10:09:12 [+0200], Peter Zijlstra wrote: > > On Wed, Oct 05, 2016 at 09:41:47AM +0200, Sebastian Andrzej Siewior wrote: > > > are those problems DL related? > > > > One of them, the other is that PI thing you did that ugly nodeboost > > thing for, right? > > this no-de-boost yes. This is probably a problem since we have this > "delayed" wake-up. I've been thinking about a marked in PI state to > ignore a de-boost so the spin_unlock() won't be a problem. But if I > understand it right, then this won't solve the DL problem since you > can't have two tasks at the same priority. The primary concern for DL right now is being able to have a stable pointer to the top waiter. We do this by having rt_mutex_setprio() update the pointer while holding both rq->lock and tsk->pi_lock. This means the pointer is stable when holding either lock, which is sufficient. But this means, we need to deboost _before_ we wake. Otherwise the task could've continued running and called do_exit() on us. Secondary, once we start looking at BWI (bandwidth inheritance), where a blocked DL task donates its runtime budget along with its deadline, we also very much need this, since a task cannot be running of its own budget while at the same time the boosted task is also running off that same budget. (having the 'blocked' DL task spin-waiting, as per optimistic spinning, makes all that rather 'interesting'). In any case, this is two problems: - your inversion issue - my pointer stability (and eventually bandwidth issue) that are caused by this hb->lock being in the way.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
[RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 17:40 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-03 17:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 18:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-03 17:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 09:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-05 10:10 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 10:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-05 10:40 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-06 12:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-07 13:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-08 18:00 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-08 19:00 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-08 19:10 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-10 12:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-10 13:50 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-08 20:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Thomas Gleixner <tglx@linutronix.de> - 2016-10-09 13:30 +0200
Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI Peter Zijlstra <peterz@infradead.org> - 2016-10-10 16:10 +0200
[RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter() Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
Re: [RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter() Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 16:20 +0200
Re: [RFC][PATCH 1/4] futex: Cleanup variable names for futex_top_waiter() Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 06:00 +0200
[RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:30 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Peter Zijlstra <peterz@infradead.org> - 2016-10-03 11:40 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Steven Rostedt <rostedt@goodmis.org> - 2016-10-03 16:30 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 03:10 +0200
Re: [RFC][PATCH 3/4] futex: Remove rt_mutex_deadlock_account_*() Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 09:40 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 03:10 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Peter Zijlstra <peterz@infradead.org> - 2016-10-05 08:30 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-10-05 09:30 +0200
Re: [RFC][PATCH 0/4] FUTEX_UNLOCK_PI wobbles Davidlohr Bueso <dave@stgolabs.net> - 2016-10-05 18:10 +0200
csiph-web