[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1308576016.531.1.camel@gandalf.stny.rr.com>
Date: Mon, 20 Jun 2011 09:20:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Hillf Danton <dhillf@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Mike Galbraith <efault@....de>,
Yong Zhang <yong.zhang0@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sched: update cpupri for runqueue when its priority
changes
On Sun, 2011-06-19 at 16:33 +0800, Hillf Danton wrote:
> On Sun, Jun 19, 2011 at 1:11 AM, Steven Rostedt <rostedt@...dmis.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists