Default "ondemand" CPU frequency management can cause 100% CPU
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mythbuntu |
Won't Fix
|
Undecided
|
Unassigned | ||
Bug Description
I can across an interesting issue with HD playback which no doubt is due to the hardware and the way I use the machine.
On my machine (AMD Athlon 64x2 4800) The CPU usage whilst playing HD content sits at ~60% with the CPU running at it's lowest speed (1GHz). With a few recordings going on the backend this starts creeping up to 80%
Occasionally another process would spawn and the CPU would find itself briefly hitting 100% - which causes dropped frames on playback - It's only brief as the cpu polling sees the increased usage and raises the frequency (so we are only talking <100ms of 100% CPU)
What I've found is by reducing the "Up_threshold" in the ondemand profile to 60%, the governor acts more cautiously, and scales up the CPU so it's running at a lower utilisation rate to begin with. This has been enough to eliminate the occasional dropped frame since there is now more idle capacity.
I've done this by adding the following to the /etc/init.
echo -n 60 > /sys/devices/
So not really a bug but more of an optimisation report - perhaps there is some customisation of the CPU power/utilisation needed with Mythtv? - delivery of content is paramount IMHO and the frontend should ensure it has the resources it needs to deliver content.
The cpu frequency scaling applied by default is very conservative, only scaling up the CPU when usage reaches 95%, this is effectively telling the governor to scale up the cpu frequency _after_ running out of CPU. For Mythtv this is not ideal. Although we can't anticipate CPU load we can at least ensure there is always some headroom. Dropping the Up_Threshold does this.
| description: | updated |
| Thomas Mashos (tgm4883) wrote | #1 |
| Changed in mythbuntu: | |
| status: | New → Won't Fix |
We really do appreciate you opening this ticket to help improve Mythbuntu, but it needs to be closed for a number of reasons. The biggest one is that upstream believes this to be fixed in the latest version. Could you please verify if this issue still exists in the latest version?
Please do not let the closing of this ticket dissuade you from opening a new ticket if this (or any other) problem occurs with the newer versions.