Re: [BISECTED] "conservative" cpufreq governor broken
From: Steven Noonan
Date: Wed Oct 07 2009 - 07:05:00 EST
On Wed, Oct 7, 2009 at 3:42 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Wed, 7 Oct 2009, Eero Nurkkala wrote:
>> For some reason, this path is taken:
>> if (ts->nohz_mode == NOHZ_MODE_INACTIVE)
>> goto end;
>
> Well, probably because the machine never switched to NOHZ :)
>
>> > 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.
>
> Don't worry, it'll go the right way. No need to cc the world and some
> more :)
>
Sorry if it's not kosher. I was told that when dealing with a
bisection you should CC:
1. those involved with a bisected patch (the Signed-off-by people),
2. those responsible for the affected subsystem (doing an author check
via script[1]),
3. and those to whom a fix should be passed on to.
Any tips so I don't bug the wrong people (or too many people) in the future?
[1] http://www.uplinklabs.net/~tycho/linux/scripts/git-authors-email.sh
(credits to Ingo for making this one. It's handy)
>>
>> From: Eero Nurkkala <ext-eero.nurkkala@xxxxxxxxx>
>> 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.
>
> Hmm, nasty that code silently relies on NOHZ functionality even when
> NOHZ is not active. That needs a big fat comment at least.
>
> Nice detective work though !
>
> Thanks,
>
> tglx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/