[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120502105532.GB22061@somewhere>
Date: Wed, 2 May 2012 12:55:35 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Michael Wang <wangyun@...ux.vnet.ibm.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
linaro-sched-sig@...ts.linaro.org,
Alessio Igor Bogani <abogani@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Avi Kivity <avi@...hat.com>,
Chris Metcalf <cmetcalf@...era.com>,
Christoph Lameter <cl@...ux.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Geoff Levand <geoff@...radead.org>,
Gilad Ben Yossef <gilad@...yossef.com>,
Hakan Akkan <hakanakkan@...il.com>,
Ingo Molnar <mingo@...nel.org>, Kevin Hilman <khilman@...com>,
Max Krasnyansky <maxk@...lcomm.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Stephen Hemminger <shemminger@...tta.com>,
Steven Rostedt <rostedt@...dmis.org>,
Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 35/41] sched: Update rq clock before idle balancing
On Wed, May 02, 2012 at 11:36:07AM +0800, Michael Wang wrote:
> On 05/01/2012 07:55 AM, Frederic Weisbecker wrote:
>
> > idle_balance() is called from schedule() right before we schedule the
> > idle task. It needs to record the idle timestamp at that time and for
> > this the rq clock must be accurate. If the CPU is running tickless
> > we need to update the rq clock manually.
> >
> > Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> > Cc: Alessio Igor Bogani <abogani@...nel.org>
> > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > Cc: Avi Kivity <avi@...hat.com>
> > Cc: Chris Metcalf <cmetcalf@...era.com>
> > Cc: Christoph Lameter <cl@...ux.com>
> > Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> > Cc: Geoff Levand <geoff@...radead.org>
> > Cc: Gilad Ben Yossef <gilad@...yossef.com>
> > Cc: Hakan Akkan <hakanakkan@...il.com>
> > Cc: Ingo Molnar <mingo@...nel.org>
> > Cc: Kevin Hilman <khilman@...com>
> > Cc: Max Krasnyansky <maxk@...lcomm.com>
> > Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Stephen Hemminger <shemminger@...tta.com>
> > Cc: Steven Rostedt <rostedt@...dmis.org>
> > Cc: Sven-Thorsten Dietrich <thebigcorporation@...il.com>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > ---
> > kernel/sched/fair.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index eff80e0..cd871e7 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -4638,6 +4638,7 @@ void idle_balance(int this_cpu, struct rq *this_rq)
> > int pulled_task = 0;
> > unsigned long next_balance = jiffies + HZ;
> >
> > + update_nohz_rq_clock(this_rq);
>
>
> I'm not sure but why we have to care nohz? if we really need an accurate
> clock, we should do the update anyway, don't we?
This concerns adaptive tickless CPUs only. So I wanted to keep the overhead
low for CPUs that are not in adaptive tickless mode. update_nohz_rq_clock()
takes care of that. It only updates the rq clock if the CPU is adaptive tickless.
>
> Some thing also confused me is the description:
> "If the CPU is running tickless we need to update the rq clock manually."
>
> I think the cpu will enter tickless mode only when the idle thread
> already switched in, then invoke
> tick_nohz_idle_enter->tick_nohz_stop_sched_tick, isn't it?
An adaptive tickless CPU tries to shutdown the tick even when the CPU
is not idle. By the time we are about to sleep and schedule the idle
task, we may be already tickless for a while.
>
> And if we invoke idle_balance for a cpu, that means it hasn't enter
> idle(current task is not idle task), so how can such a cpu in tickless mode?
>
> Regards,
> Michael Wang
>
> > this_rq->idle_stamp = this_rq->clock;
> >
> > if (this_rq->avg_idle < sysctl_sched_migration_cost)
>
> --
> 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/
--
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