[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1323997138.1984.274.camel@sbsiddha-desk.sc.intel.com>
Date: Thu, 15 Dec 2011 16:58:58 -0800
From: Suresh Siddha <suresh.b.siddha@...el.com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linaro-dev@...ts.linaro.org" <linaro-dev@...ts.linaro.org>,
"patches@...aro.org" <patches@...aro.org>,
Ingo Molnar <mingo@...e.hu>, Paul Turner <pjt@...gle.com>
Subject: Re: [RFC] sched: Ensure cpu_power periodic update
On Thu, 2011-12-15 at 05:36 -0800, Vincent Guittot wrote:
> I'm using cyclictest to easily reproduce the problem on my dual cortex-A9
So does the cyclictest itself exhibit the problem or running cyclictest
with another workload showed the problem? In other words, what numbers
of the workload did you see change with this patch?
>
> > Then again, its probably easier to keep update_group_power on this_cpu
> > than to allow a remote update of your cpu_power.
> >
>
> This additional path for updating the cpu_power will only be used by
> this_cpu because it is called by idle_balance. But we still have a
> call to update_group_power by a remote cpu when nohz_idle_balance is
> called.
As Vincent mentioned, the current mainline kernel already updates the
remote cpu's group_power in the nohz idle load balancing patch.
Also with all the recent nohz idle load balancing using kick, on a
dual-core system there may not be any nohz idle load balancing if
multiple tasks wakeup, run for short time and go back to idle before the
next tick. We rely on the wakeup balance to get it right in this case.
thanks,
suresh
--
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