Re: [PATCH] sched: update cpupri for runqueue when its prioritychanges

[Steven Rostedt]

On Sat, 2011-06-18 at 22:54 +0800, Hillf Danton wrote:

> >> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> >> index 08e9374..9508168 100644
> >> --- a/kernel/sched_rt.c
> >> +++ b/kernel/sched_rt.c
> >> @@ -1158,6 +1158,8 @@ static struct task_struct
> >> *pick_next_task_rt(struct rq *rq)
> >>          * lock again later if there is no need to push
> >>          */
> >>         rq->post_schedule = has_pushable_tasks(rq);
> >> +
> >> +       cpupri_set(&rq->rd->cpupri, rq->cpu, p == NULL ? MAX_RT_PRIO : p->prio);
> >
> > In pick_next_task_rt(), p is the highes prio that is queued. Thus,
> > cpupri is already set to p->prio. If p is NULL, then there is no rt
> > tasks queued on this rq, and cpupri is set to MAX_RT_PRIO. Your patch
> > here does not change anything.
> >
> 
> There are two cases that NULL is returned in _pick_next_task_rt(), it is the
> second case, after checking rt_rq->rt_nr_running, that is captured, and if
> NULL is returned in the second case, the CPU priority does change.

The two cases are:

1) no rt task exists
2) the runqueue is throttled.

We already talked about the throttled case. The case where no rt task
exists means that the last rt task has been dequeued. When that happens,
the cpupri is updated then. I don't see any bug. There's no need to
update cpupri at this point.

> 
> In another scenario that has little with {en, de}queue, as shown by
> requeue_task_rt(), the CPU priority will change if other RT tasks exist.
> 

The requeue_task_rt() does not change the priority of the CPU. It just
updates the task in its order of placement in the queue of other tasks
of the same priority.

-- Steve


--
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/