Re: Bug in scheduler when using rt_mutex

From: Yong Zhang
Date: Thu Jan 20 2011 - 04:07:27 EST


On Thu, Jan 20, 2011 at 4:37 PM, Mike Galbraith <efault@xxxxxx> wrote:
> On Thu, 2011-01-20 at 15:06 +0800, Yong Zhang wrote:
>> On Thu, Jan 20, 2011 at 2:12 PM, Mike Galbraith <efault@xxxxxx> wrote:
>> > If the task returns as a sleeper, place entity() will be called when it
>> > is awakened, so it's sleep credit will be clipped as usual. ÂSo vruntime
>> > can be much less than min_vruntime at class exit time, and it doesn't
>> > matter, clipping on wakeup after re-entry takes care of it.. if that's
>> > what you were thinking about.
>>
>> For a sleep task which stay in sched_fair before it's waked:
>> try_to_wake_up()
>> Â ttwu_activate()
>> Â Â activate_task()
>> Â Â Â enqueue_task_fair()
>> Â Â Â Â enqueue_entity()
>> Â Â Â Â Â place_entity() Â Â Â Â<== clip vruntime
>>
>> For a sleep task which promote to sched_rt when it's sleep:
>> rt_mutex_setprio()
>> Â check_class_changed()
>> Â Â switch_from_fair() Â Â Â <== vruntime -= min_vruntime
>> Â Â Â try_to_wake_up()
>> Â Â Â Â ...run then stay on rq
>> Â Â Â Â rt_mutex_setprio()
>> Â Â Â Â Â enqueue_task_fair() Â Â <==vruntime += min_vruntime
>>
>> The difference is that in the second case, place_entity() is not
>> called, but wrt sched_fair, the task is a WAKEUP task.
>> Then we place this task in sched_fair before where it should be.
>
> D'oh. ÂYou're right, he needs to be clipped before he leaves.

Exactly we should clip it when it comes back, because it still could
sleep for some time after it leaves ;)

Thanks,
Yong

--
Only stand for myself
--
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/