Re: Bug in scheduler when using rt_mutex

[Mike Galbraith <efault@gmx.de>]

On Thu, 2011-01-20 at 17:07 +0800, Yong Zhang wrote:
> On Thu, Jan 20, 2011 at 4:37 PM, Mike Galbraith <efault@gmx.de> 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@gmx.de> 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 ;)

That's ok, we don't and aren't supposed to care what happens while he's
gone.  But we do have to make sure that vruntime is sane either when he
leaves, or when he comes back.  Seems to me the easiest is clip when he
leaves to cover him having slept a long time before leaving, then coming
back on us as a runner.  If he comes back as a sleeper, he'll be clipped
again anyway, so all is well.

sched_fork() should probably zero child's vruntime too, so non-fair
children can't enter fair_class with some bogus lag they never had.

	-Mike