Mageia forum

I made an interesting discovery regarding CPU frequency throttling. The application recomended by Red Hat for this task is cpupower. But the default profile for cpupower is "on demand". With "on demand" I was getting brief UI freezes when running CPU intensive operations like btrfs scrub. And unfortunately, it is difficult to throttle btrfs scrub as a process since neither nice nor cpulimit do the job easily. The problem with "on demand" is that it is overactive in ratcheting CPU frequency up and down which results in some degree of latency where the resource governor can not keep up with the shifting load. I found a better choice to be "conservative" which maintains a higher power level longer before dropping it down again as is seeming to produce a much smoother ride for desktop usage. You won't save quite as much power, but CPU intensive applications will be considerably less noticable as the CPU will be set loose until the load has settled. The key config file to look for is /etc/sysconfig/cpupower. Also make sure you are running only ONE version of CPU power modulation. There are multiple apps available. Only one should be installed. - George

Nice. Thanks!

I discovered this problem through hard experience some time ago when I initially posted this. But now this comes out:http://www.phoronix.com/scan.php?page=news_item&px=MTM3NDQ. In light of this disclosure, I believe that "ondemand" profile should NOT be the default profile for cpupower or cpufreq which also defaults to "ondemand". I don't know if it still is currently, but it was when I originally installed cpupower. Perhaps someone at Mageia could look into this or should I file a bug report against cpupower and see what it turns up? Or is this something that is totally controlled by upstream? My concern is that user complaints could perhaps be avoided by somehow fixing this at the distro level. For power saving with reasonable performance, I am finding that the "conservative" profile works well. - George

Please file bug to alert developers to discuss.

Bug report filed: https://bugs.mageia.org/show_bug.cgi?id=10405

This is quit hard to fix it in mageia 3,but you should change that report against cauldron so they fix it in next stable release.

At this point it looks like someone IS looking at it in relation to Mageia3. I should not think it should be that difficult to change the default governor on Mageia 3. But you are correct in asserting that the Cauldren side should be addressed as well. As I would rather not confuse the issue (and myself) by adding a bug report against Cauldren, if any of you all would be willing to do so and link it here, I would appreciate that. My immediate interest is with Mageia 3, since that is what I plan to be using for an extended time. The Cauldren side should be addressed by someone who follows Cauldren a whole lot closer than I do.

I tested this and that consernative slows down my laptop and makes it slow as hell,so i needed to change it back to ondemand.

For what it is worth, I am running an Asus Sabertooth 990FX R2 motherboard with an AMD Phenom-II 955 quad-core processor. This is the first Linux system I have run where I enabled the AMD "Cool n Quiet" feature and left it on; in all previous systems, I had noticed performance impacts that were sufficiently severe to cause me to disable the feature in BIOS and not run any power management in the system.

My system is set to "ondemand" and I have noticed no performance issues. In fact, I am continually monitoring CPU temperatures and clocks, and I find the behavior of the system to be excellent. I do at some times experience "stuttering" of the KDE interface, but this seems related to a memory leak in X as opposed to anything else, and clearly is dependent upon how long KDE and X have been up and running.