[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1254907901.30157.93.camel@eenurkka-desktop>
Date: Wed, 07 Oct 2009 12:31:41 +0300
From: Eero Nurkkala <ext-eero.nurkkala@...ia.com>
To: ext Steven Noonan <steven@...inklabs.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Rik van Riel <riel@...hat.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Greg KH <greg@...ah.com>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [BISECTED] "conservative" cpufreq governor broken
On Wed, 2009-10-07 at 10:52 +0200, ext Steven Noonan wrote:
> On Wed, Oct 7, 2009 at 1:43 AM, Eero Nurkkala
> <ext-eero.nurkkala@...ia.com> wrote:
> > On Wed, 2009-10-07 at 10:24 +0200, ext Steven Noonan wrote:
> >> >
> >> > Steven, how do the cpu loads look like without the patch?
> >>
> >> They're sane:
> >>
> >> [ 40.019381] cpufreq load = 100 * (66666 - 66337) / 66666 = 0
> >> [ 40.019396] cpufreq load = 100 * (66666 - 66299) / 66666 = 0
> >> [ 73.352580] cpufreq load = 100 * (66717 - 66349) / 66717 = 0
> >> [ 73.352595] cpufreq load = 100 * (66634 - 63848) / 66634 = 4
> >
> > Thank you. Could you please try the following:
> > Now, if ts->nohz_mode == NOHZ_MODE_INACTIVE, ts->inidle is not set
> > and all subsequent calls from irq_exit() think we weren't idling,
> > which is not true.
> >
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -233,6 +233,8 @@ void tick_nohz_stop_sched_tick(int inidle)
> >
> > now = tick_nohz_start_idle(ts);
> >
> > + ts->inidle = 1;
> > +
> > /*
> > * If this cpu is offline and it is the one which updates
> > * jiffies, then give up the assignment and let it be taken by
> > @@ -248,8 +250,6 @@ void tick_nohz_stop_sched_tick(int inidle)
> > if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))
> > goto end;
> >
> > - ts->inidle = 1;
> > -
> > if (need_resched())
> > goto end;
> >
>
> Yeah, that fixed it. The load is now sane, my system isn't heating up,
> and 'conservative' is now clocking my CPU down to the minimum as is
> appropriate.
>
For some reason, this path is taken:
if (ts->nohz_mode == NOHZ_MODE_INACTIVE)
goto end;
> Can you explain why this only affected 'conservative', why it caused
> my machine to heat up, etc?
>
Maybe the loads dont look good with ondemand either? if you trace them
out. Below is a patch that has explanation on what's happening in
your system.
> Also, this fix should probably be passed on to Greg K. H. (so it goes
> in 2.6.31-stable) as well as Ingo Molnar (so it goes into -tip, and
> hopefully to Linus for 2.6.32). Both CC'd.
>
> - Steven
From: Eero Nurkkala <ext-eero.nurkkala@...ia.com>
Date: Wed, 7 Oct 2009 11:54:26 +0300
Subject: [PATCH] NOHZ: update idle state properly
Commit f2e21c9610991e95621a81407cdbab881226419b
had unfortunate side effects with cpufreq governors on
some systems.
If NOHZ_MODE_INACTIVE was set, ts->inidle was not being
set. Then, all subsequent calls from irq_exit() bypassed
calls to tick_nohz_start_idle() which resulted in wrong
information passed to cpufreq governors. Fix this by
updating the state of ts->inidle where it fits the best.
Reported-by: Steven Noonan <steven@...inklabs.net>
Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@...ia.com>
---
kernel/time/tick-sched.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index e0f59a2..4c1b0ac 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -233,6 +233,8 @@ void tick_nohz_stop_sched_tick(int inidle)
now = tick_nohz_start_idle(ts);
+ ts->inidle = 1;
+
/*
* If this cpu is offline and it is the one which updates
* jiffies, then give up the assignment and let it be taken by
@@ -248,8 +250,6 @@ void tick_nohz_stop_sched_tick(int inidle)
if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))
goto end;
- ts->inidle = 1;
-
if (need_resched())
goto end;
--
1.6.0.4
--
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