From: Daniel J Blueman <daniel.blueman@gmail.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: ondemand cpufreq ineffective in 2.6.12 ?
Date: Tue, 12 Jul 2005 12:07:56 +0100 [thread overview]
Message-ID: <6278d22205071204073a6de1a2@mail.gmail.com> (raw)
I find the ondemand governor works as expected with 2.6.12 on my
Athlon64 Winchester [1]; as soon as I bzip2 a file, processor freq is
pinned at 1.8GHz and drops to 1GHz when idle.
--- [1]
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 31
model name : AMD Athlon(tm) 64 Processor 3000+
stepping : 0
cpu MHz : 1004.646
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow
bogomips : 1988.83
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
Ken Moffat wrote:
> Hi,
>
> I've been using the ondemand governor on athlon64 winchesters for a few
> weeks. I've just noticed that in 2.6.12 the frequency is not
> increasing under load, it remains at the lowest frequency. This seems
> to be down to something in 2.6.12-rc6, but I've seen at least one report
> since then that ondemand works fine. Anybody else seeing this problem ?
>
> Testcase: boot (my bootscripts set the governor to ondemand), set the
> governor to ondemand, performance, powersave and untar a nice big
> bzip2'd tarball (gcc-3.4.1) from an nfs mount. All using the config from
> 2.6.11.9 and defaults for new options.
>
> kernel 2.6.11.9 2.6.12-rc5 2.6.12-rc6 2.6.12
>
> ondemand 20.8 sec 21.3 sec 33.9 sec 34.1 sec
> performance 21.3 sec 22.0 sec 22.6 sec 20.1 sec
> powersave 32.4 sec 33.1 sec 33.6 sec 33.9 sec
>
> I don't have confidence that the numbers are more repeatable than +/- 2
> seconds on this, they just illustrate that ondemand used to give a
> similar time to performance, but now doesn't. Other intermediate and
> later tests have been omitted for clarity, but 2.6.12.2 does show the
> same problem.
>
> Since 2.6.12-rc6, 'ondemand' appears to be still accepted (the echo to
> scaling_governor returns 0, and the displayed frequency drops back if
> I try going from performance to ondemand).
>
> When ondemand appears to work properly, /proc/cpuinfo shows the speed
> jumping to 2 GHz, then falling back to 1.8 after the untar ends, then
> back to 1.0 GHz. In the problem cases, the speed remains at 1GHz.
>
> As far as I can see, nothing untoward shows in the logs. Any
> suggestions, please ?
>
> Ken
___
Daniel J Blueman
next reply other threads:[~2005-07-12 11:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-12 11:07 Daniel J Blueman [this message]
2005-07-12 11:35 ` ondemand cpufreq ineffective in 2.6.12 ? Ken Moffat
-- strict thread matches above, loose matches on Subject: below --
2005-07-11 16:25 Ken Moffat
2005-07-11 19:45 ` Ken Moffat
2005-07-11 21:55 ` Con Kolivas
2005-07-12 7:58 ` Eric Piel
2005-07-12 10:37 ` Ken Moffat
2005-07-12 11:11 ` Ken Moffat
2005-07-12 11:49 ` Eric Piel
2005-07-12 11:52 ` Con Kolivas
2005-07-12 14:57 ` Lee Revell
2005-07-12 21:26 ` Con Kolivas
2005-07-12 13:30 ` Ken Moffat
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=6278d22205071204073a6de1a2@mail.gmail.com \
--to=daniel.blueman@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.