Bug 36652 - Ondemand governor is hyperactive
Summary: Ondemand governor is hyperactive
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-04 16:50 UTC by timshel
Modified: 2012-05-24 08:00 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.39
Subsystem:
Regression: No
Bisected commit-id:


Attachments
cpufreq.patch (1.53 KB, patch)
2011-06-04 17:42 UTC, Markus Trippelsdorf
Details | Diff

Description timshel 2011-06-04 16:50:05 UTC
According to some posts Ondemand governor should be the best even in battery mode because the cpu can sleep longer if the tasks get finished sooner.

This is probably true but at the moment it isn't because Ondemand even scales up if the cpu doesn't has anything to do.
This might have something to do that the governor can't anticipate how long or how much this task will need so he scales up all the time if the cpu is used but this is bad in battery mode.

So either there is a bug in Ondemand governor which should be fixed or if this happens purely out of performance reasons there should be an additional mode for battery where it only scales up if the cpu can't handle this with the lowest task.

I know that there is the conservative governor but it is too slow, for example it takes ages to scale down.

With powersave the battery time is increased significantly (at least 1W less) and for most tasks the lowest frequency is fine.

I mean in this idle case of the screen shot it doesn't make any sense to scale up all the time but even if you play a video there is no need for the highest frequency and especially not the turbo mode.

I mean why are there more than two frequencies if only they get used?

I am using openSUSE 11.4 with Kernel 2.6.37. I had the same problem with Vanilla 2.6.39.
My processor is a Core i5 of the first generation.

If you need any additional information let me know.
Comment 1 Markus Trippelsdorf 2011-06-04 17:37:09 UTC
I see similar symptoms in >=2.6.38 as described here:
http://thread.gmane.org/gmane.linux.kernel.cpufreq/7167

Can you try to revert commit 5cb2c3bd0c5e0f3ced63f250ec2ad59d7c5c626a
and see if it makes any difference in your case?
Comment 2 Markus Trippelsdorf 2011-06-04 17:42:42 UTC
Created attachment 60802 [details]
cpufreq.patch

And if you don't use git, you could just apply this patch.
Comment 3 timshel 2011-06-10 07:46:59 UTC
Sorry for the delay but I was on vacation.
I have the same problem with Kernel 2.6.37 where your patch is already replied.
Comment 4 Markus Trippelsdorf 2011-06-10 07:58:20 UTC
Yes, sorry 5cb2c3bd0c was a red herring.
Comment 5 Zhang Rui 2012-01-18 05:18:56 UTC
It's great that the kernel bugzilla is back.

Can you please verify if the problem still exists in the latest upstream
kernel?
Comment 6 Zhang Rui 2012-05-24 08:00:01 UTC
bug closed as there is no response from the bug reporter.
please feel free to reopen it if the problem still exists in the latest upstream kernel.

Note You need to log in before you can comment on or make changes to this bug.