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

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 2011-06-19 at 16:33 +0800, Hillf Danton wrote:
> On Sun, Jun 19, 2011 at 1:11 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >> 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 case 2) , the CPU will be held then by non-RT task, and we have to
> update priority.
> 
> I understand 1) and 2) to be, there has RT tasks on runqueue but they
> could not run at the moment.
> 
> If throttled RQ == no RT tasks, please drop this patch directly.

Yes a throttled RQ means that there are no RT tasks on it. That's
because when we throttle an RQ, we dequeue the RT tasks from it. Which
means the cpupri will be updated at that time.

-- Steve