[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2EF88150C0EF2C43A218742ED384C1BC0FC85433@IRVEXCHMB08.corp.ad.broadcom.com>
Date: Wed, 21 Mar 2012 18:33:45 +0000
From: "Michael J. Wang" <mjwang@...adcom.com>
To: "Peter Zijlstra" <peterz@...radead.org>
cc: "Yong Zhang" <yong.zhang0@...il.com>,
"mingo@...e.hu" <mingo@...e.hu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"Michael J. Wang" <mjwang@...adcom.com>
Subject: RE: [PATCH 1/1] scheduler: minor improvement to
pick_next_highest_task_rt in linux-3.3
> From: Peter Zijlstra [mailto:peterz@...radead.org]
> Sent: Wednesday, March 21, 2012 2:07 AM
> To: Michael J. Wang
> Cc: Yong Zhang; mingo@...e.hu; linux-kernel@...r.kernel.org;
> rostedt@...dmis.org
> Subject: RE: [PATCH 1/1] scheduler: minor improvement to
> pick_next_highest_task_rt in linux-3.3
>
> On Wed, 2012-03-21 at 07:49 +0000, Michael J. Wang wrote:
> > > > Should I reformat my patch and send it again?
> > >
> > > It'll be better, and I think Peter/Ingo will happy with it.
> > >
> >
> > OK. I will resend now. Thanks for all your help!
>
> The resend didn't include the more details thing, so I fudged it by
> hand. The queued thing now looks like this:
>
OK. Thanks. I was afraid the details were too verbose when the fix
was obvious to the experts. Anyways, I now know the format you
are expecting, so I will do better next time.
Michael
> ---
> Subject: sched, rt: Minor improvement to pick_next_highest_task_rt
> From: Michael J Wang <mjwang@...adcom.com>
> Date: Mon, 19 Mar 2012 22:26:19 +0000
>
> Avoid extra work by continuing on to the next rt_rq if the highest
> prio task in current rt_rq is the same priority as our candidate
> task.
>
> More detailed explanation: if next is not NULL, then we have found a
> candidate task, and its priority is next->prio. Now we are looking
> for an even higher priority task in the other rt_rq's. idx is the
> highest priority in the current candidate rt_rq. In the current 3.3
> code, if idx is equal to next->prio, we would start scanning the tasks
> in that rt_rq and replace the current candidate task with a task from
> that rt_rq. But the new task would only have a priority that is equal
> to our previous candidate task, so we have not advanced our goal of
> finding a higher prio task. So we should avoid the extra work by
> continuing on to the next rt_rq if idx is equal to next->prio.
>
> Signed-off-by: Michael J Wang <mjwang@...adcom.com>
> Acked-by: Steven Rostedt <rostedt@...dmis.org>
> Reviewed-by: Yong Zhang <yong.zhang0@...il.com>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Link:
> http://lkml.kernel.org/r/2EF88150C0EF2C43A218742ED384C1BC0FC83D6B@IRVEX
> CHMB08.corp.ad.broadcom.com
> ---
> kernel/sched/rt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -1428,7 +1428,7 @@ static struct task_struct *pick_next_hig
> next_idx:
> if (idx >= MAX_RT_PRIO)
> continue;
> - if (next && next->prio < idx)
> + if (next && next->prio <= idx)
> continue;
> list_for_each_entry(rt_se, array->queue + idx, run_list) {
> struct task_struct *p;
>
--
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