On Wed, Apr 20, 2016 at 02:43:29PM +0200, Thomas Gleixner wrote: > > So its semantically icky to have the two tasks running off the same > > state and practically icky when you consider bandwidth inheritance -- > > where the boosted task wants to explicitly modify the state of the > > booster. > > > > In that latter case you really want to unboost before you let the > > booster run again. > > I understand that. That doesn't make the changelog any better, which mumbles > about priorities :(
Agreed. > > However, you noted we need to deal with this case due to the whole > > optimistic spinning crap anyway :/ > > Right, but that's another dimension of madness. Both tasks are on a cpu. > The reason why we boost the lock holder before spinning is to make > sure that it does not get preempted by something of medium priority > before dropping the lock. Right; I figured that out pretty quickly, which is why this patch does a preempt_disable() over the unboost+wakeup. FWIW, the immediate reason for this patch is that is ensures the new p->pi_task pointer, points to something that exists. > That really gets interesting with bandwith inheritance .... I'm more worried about the optimistic spinning case..
