On 04/03/2013 01:08 PM, Namhyung Kim wrote: >> > - for_each_cpu(i, sched_group_cpus(group)) >> > - sgs->group_util += max_rq_util(i); >> > + for_each_cpu(i, sched_group_cpus(group)) { >> > + struct rq *rq = cpu_rq(i); >> > + >> > + if (burst && rq->nr_running > 1) >> > + /* use nr_running as instant utilization */ >> > + sgs->group_util += rq->nr_running; > I guess multiplying FULL_UTIL to rq->nr_running here will remove > special-casing the burst in is_sd_full(). Also moving this logic to > max_rq_util() looks better IMHO. > >
Thanks Namhyung! patch updated. >From b6384f4e3294e19103f706195a95265faf1ea7ef Mon Sep 17 00:00:00 2001 From: Alex Shi <alex....@intel.com> Date: Mon, 25 Mar 2013 16:07:39 +0800 Subject: [PATCH 12/21] sched: using avg_idle to detect bursty wakeup Sleeping task has no utiliation, when they were bursty waked up, the zero utilization make scheduler out of balance, like aim7 benchmark. rq->avg_idle is 'to used to accommodate bursty loads in a dirt simple dirt cheap manner' -- Mike Galbraith. With this cheap and smart bursty indicator, we can find the wake up burst, and use nr_running as instant utilization in this scenario. For other scenarios, we still use the precise CPU utilization to judage if a domain is eligible for power scheduling. Thanks for Mike Galbraith's idea! Thanks for Namhyung's suggestion to compact the burst into max_rq_util()! Signed-off-by: Alex Shi <alex....@intel.com> --- kernel/sched/fair.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index f610313..a729939 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3363,6 +3363,10 @@ static unsigned int max_rq_util(int cpu) unsigned int cfs_util; unsigned int nr_running; + /* use nr_running as instant utilization for burst cpu */ + if (cpu_rq(cpu)->avg_idle < sysctl_sched_burst_threshold) + return rq->nr_running * FULL_UTIL; + /* yield cfs utilization to rt's, if total utilization > 100% */ cfs_util = min(rq->util, (unsigned int)(FULL_UTIL - rt_util)); -- 1.7.12 -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/