On 10/10/18 12:43, luca abeni wrote: > Hi, > > On Tue, 9 Oct 2018 11:24:29 +0200 > Juri Lelli <juri.lelli@xxxxxxxxxx> wrote: > > > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > > > > Track the blocked-on relation for mutexes, this allows following this > > relation at schedule time. Add blocked_task to track the inverse > > relation. > > > > ,-> task > > | | blocked-on > > | v > > blocked-task | mutex > > | | owner > > | v > > `-- task > > I was a little bit confused by this description, because (if I > understand the code well) blocked_task does not actually track the > inverse of the "blocked_on" relationship, but just points to the task > that is _currently_ acting as a proxy for a given task. > > In theory, we could have multiple tasks blocked on "mutex" (which is > owned by "task"), so if "blocked_task" tracked the inverse of > "blocked_on" it should have been a list (or a data structure containing > pointers to multiple task structures), no? > > I would propose to change "blocked_task" into something like > "current_proxy", or similar, which should be more clear (unless I > completely misunderstood this stuff... In that case, sorry about the > noise) Makes sense to me. It looks also closer to what comment says. > Also, I suspect that this "blocked_task" (or "current_proxy") field > should be introcuced in patch 5 (same for the "task_is_blocked()" > function from patch 4... Should it go in patch 5?) Sure. I believe I might have wrongly split things while rebasing. Will fix. Thanks, - Juri
