Re: [RFC][PATCH 0/3] Refactoring sched_entity and sched_rt_entity.

[Lucas De Marchi]

On Tue, Jan 4, 2011 at 15:58, Dario Faggioli <raistlin@xxxxxxxx> wrote:
> On Tue, 2011-01-04 at 14:37 -0200, Lucas De Marchi wrote:
>> > Suggestions on how to deal with that will be appreciated.
>>
>> Don't forget the PI case too. You will need to change
>> rt_mutex_setprio() to keep a copy of sched_cfs_entity in struct
>> rt_mutex_waiter.
>>
> Mmm... do I? While I'm cloning your git, could you elaborate a bit on
> why, because I don't seem to see that... :-P

Suppose a RT task blocks on a PI-mutex, the lock owner will be boosted
to RT and go through a class change in rt_mutex_setprio().
Since now a class change reinitializes the class-specific, if fair and
rt fields are on the same memory space, we need to save the
sched_fair_entity before changing the class to RT and put it again
when going back to the fair class.

Quoting Peter about this:

 [ Initially I was thinking not, because the task slept we'll have to
reinsert it in the rb-tree anyway, but upon further consideration
that'll loose the old vruntime setting, which can lead to an unseemly
gain of time in place_entity()'s never backward check failing.

So yes, we'd have to place a copy of the old sched_entity in struct
rt_mutex_waiter, not very hard to do. ]


As a side-note: irc this is one thing i didn't do when i prepared that patches.



Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/