Red Hat Bugzilla – Bug 386161
cpu stay slow when running nice >0
Last modified: 2007-11-30 17:12:22 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.9) Gecko/20071105 Fedora/2.0.0.9-1.fc8 Firefox/2.0.0.9 Description of problem: cpu speed stay at 1.60 GHz (2.13 GHz Core2Duo) and wont go to full 2.13 when running programm with nice setting > 0 (ie nice -n 1). still want full power to application when not doing anything else but leave priority to other application running the same application on different data on each core. Version-Release number of selected component (if applicable): cpuspeed-1.2.1-3.fc8 How reproducible: Always Steps to Reproduce: 1.nice -n 1 application1 2.nice -n 1 application2 3. Actual Results: processor usage go to 100% speed stay at 1.6 GHz Expected Results: speed switch to 2.13GHz as was the case if F7 Additional info:
This behavior is controlled by the the value of /sys/devices/system/cpu/cpu[0-9]*/cpufreq/ondemand/ignore_nice_load, which it would appear you have set to 1. Sounds like basically what you want to do is flip the ignore_nice_load value to 0 for all your cpus. Documentation/cpu-freq/governors.txt in the kernel source says the following: ignore_nice_load: this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency. This should be configurable via the IGNORE_NICE param in /etc/sysconfig/cpuspeed, so just bounce cpuspeed after changing the value and you should be all set. Of course, my own system has IGNORE_NICE=0 in its config file, and the actual system state was 1 until I restarted cpuspeed a minute ago, so something else may be amiss too... (I'm wondering if gnome twiddles that at all). But I'm pretty sure there's not a bug in either cpuspeed or the kernel.