mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Noonan <steven@uplinklabs.net>
To: ext-eero.nurkkala@nokia.com
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rik van Riel <riel@redhat.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Subject: Re: [BISECTED] "conservative" cpufreq governor broken
Date: Wed, 7 Oct 2009 01:11:38 -0700	[thread overview]
Message-ID: <f488382f0910070111x49fdb565p50d29786540bbb3f@mail.gmail.com> (raw)
In-Reply-To: <f488382f0910070105g19cbf75ci8034f2917b7e5606@mail.gmail.com>

On Wed, Oct 7, 2009 at 1:05 AM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Wed, Oct 7, 2009 at 12:49 AM, Eero Nurkkala
> <ext-eero.nurkkala@nokia.com> wrote:
>> On Wed, 2009-10-07 at 09:30 +0200, ext Steven Noonan wrote:
>>>
>>> Okay, wow, I'm a moron. I misread what cpu_idle() was intended to be
>>> for. I thought that cpu_idle() was a function that was periodically
>>> called whenever the CPU had nothing to do, but now I see that it's
>>> actually the main loop. I should really read the code next time.
>>>
>>> I've moved the statistics printout code to the _inside_ of that
>>> infinite loop and retested. I had it print every several hundred
>>> iterations. Here's the results (note the machine was idle the whole
>>> time, except for about the first 10-20 seconds while the machine
>>> booted):
>>>
>>> [    3.627716] timings[0]: 2250511125 / 3627716116
>>> [    6.946216] timings[0]: 4780901366 / 6946213531
>>> [   13.355182] timings[0]: 9385417604 / 13355183525
>>> [   18.551304] timings[1]: 16300853077 / 18551301189
>>> [   21.589039] timings[0]: 15984495433 / 21589037480
>>> [   47.152733] timings[1]: 44386121538 / 47152731476
>>> [   51.682630] timings[0]: 45713834076 / 51682628295
>>> [   79.587359] timings[0]: 73524821916 / 79587356820
>>> [   88.630110] timings[1]: 85324277596 / 88630109605
>>> [   96.082386] timings[0]: 89691306072 / 96082384539
>>>
>>
>> Those look good.
>>
>> Well, might as well then go for:
>> /drivers/cpufreq/cpufreq_conservative.c
>> dbs_check_cpu() ->
>> load = 100 * (wall_time - idle_time) / wall_time; <- What is your load?
>
> That's probably the problem...
>
> [   40.632277] cpufreq load = 100 * (66667 - 3310) / 66667 = 95
> [   40.698947] cpufreq load = 100 * (66661 - 3238) / 66661 = 95
> [   73.965425] cpufreq load = 100 * (66667 - 12820) / 66667 = 80
> [   74.032095] cpufreq load = 100 * (66661 - 1124) / 66661 = 98
> [  107.298571] cpufreq load = 100 * (66666 - 13092) / 66666 = 80
> [  107.365301] cpufreq load = 100 * (66722 - 3317) / 66722 = 95
> [  140.631717] cpufreq load = 100 * (66666 - 3311) / 66666 = 95
> [  140.698387] cpufreq load = 100 * (66662 - 3237) / 66662 = 95
>
> idle_time is wrong.

Actually, it's more likely that the idle_time there is correct and
there's something else that's going runaway. My system's fans are
running at about 4000 RPM, when they'd normally be running at 2000 RPM
for this load average. I suspect there's something actually going
wild.

>
>> Let assume load is sane, look for (in dbs_check_cpu())
>>        if (load < (dbs_tuners_ins.down_threshold - 10)) {
>>
>> whether it is taken ever...if not, what is your
>> (dbs_tuners_ins.down_threshold - 10) ?
>>
>> - Eero
>>
>>
>

  reply	other threads:[~2009-10-07  8:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05 16:32 Steven Noonan
2009-10-06  7:31 ` Eero Nurkkala
2009-10-06 10:22   ` Steven Noonan
2009-10-06 10:43     ` Eero Nurkkala
2009-10-06 11:22       ` Steven Noonan
2009-10-06 12:36         ` Eero Nurkkala
2009-10-07  0:54           ` Steven Noonan
2009-10-07  1:22             ` Steven Noonan
2009-10-07  5:27               ` Eero Nurkkala
2009-10-07  7:30                 ` Steven Noonan
2009-10-07  7:49                   ` Eero Nurkkala
2009-10-07  8:05                     ` Steven Noonan
2009-10-07  8:11                       ` Steven Noonan [this message]
2009-10-07  8:14                       ` Eero Nurkkala
2009-10-07  8:24                         ` Steven Noonan
2009-10-07  8:43                           ` Eero Nurkkala
2009-10-07  8:52                             ` Steven Noonan
2009-10-07  9:31                               ` Eero Nurkkala
2009-10-07 10:42                                 ` Thomas Gleixner
2009-10-07 11:03                                   ` Steven Noonan
2009-10-07 11:15                                     ` Thomas Gleixner
2009-10-07 11:06                                 ` [tip:timers/urgent] NOHZ: update idle state also when NOHZ is inactive tip-bot for Eero Nurkkala
2009-10-07 13:35                                   ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f488382f0910070111x49fdb565p50d29786540bbb3f@mail.gmail.com \
    --to=steven@uplinklabs.net \
    --cc=ext-eero.nurkkala@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®