From: Con Kolivas <kernel@kolivas.org>
To: linux-kernel@vger.kernel.org
Cc: Ken Moffat <ken@kenmoffat.uklinux.net>
Subject: Re: ondemand cpufreq ineffective in 2.6.12 ?
Date: Tue, 12 Jul 2005 07:55:00 +1000 [thread overview]
Message-ID: <200507120755.03110.kernel@kolivas.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0507112044001.3450@ppg_penguin.kenmoffat.uklinux.net>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
On Tue, 12 Jul 2005 05:45, Ken Moffat wrote:
> On Mon, 11 Jul 2005, 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 ?
>
> And just for the record, it's still not working in 2.6.13-rc2. Oh
> well, back to 2.6.11 for this box.
I noticed a change in ondemand on pentiumM, where it would not ramp up if the
task using cpu was +niced. It does ramp up if the task is not niced. This
seems to have been considered all round better but at my end it is not - if
it takes the same number of cycles to complete a task it does not save any
battery running it at 600Mhz vs 1700Mhz, it just takes longer. Yes I know
during the initial ramp up the 1700Mhz one will waste more battery, but that
is miniscule compared to something that burns cpu constantly for 10 mins. Now
I'm forced to run my background tasks at nice 0 and not get the benefit of
nicing the tasks, _or_ I have to go diddling with settings in /sys to disable
this feature or temporarily move to the performance governor. Although I
complained lightly initially when this change was suggested, I didn't realise
it was actually going to become standard.
To me the ondemand governor was supposed to not delay you at all, but cause as
much battery saving as possible without noticeable slowdown...
Oh well you can't please everyone all the time.
Con
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-11 21:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 16:25 ondemand cpufreq ineffective in 2.6.12 ? Ken Moffat
2005-07-11 19:45 ` Ken Moffat
2005-07-11 21:55 ` Con Kolivas [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2005-07-12 11:07 Daniel J Blueman
2005-07-12 11:35 ` 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=200507120755.03110.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=ken@kenmoffat.uklinux.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox