Description of problem: When I run a long compile on my laptop, I
typically run it with a positive nice value so that everything else
I'm doing remains more responsive. However, cpuspeed doesn't consider
niced processes to be part of the activity ratio that it uses when
determining what speed the CPU should be running at. This means that
my compiles take longer when they're niced since the CPU is running at
a slower speed, which is not what I want. This seems typical of niced
processes -- they're niced so that they don't take away time from
other things, but not so that they run slower even when there's
nothing else running. I think cpuspeed should consider cpu time spent
handling niced processes as activity.
Version-Release number of selected component (if applicable):
How reproducible: every time
Steps to Reproduce:
1. execute a compile with a positive nice value (e.g., nice -n 12 make
2. watch the output of 'grep MHz /proc/cpuinfo'
Actual results: CPU runs at slow speed for a niced compile
Expected results: CPU runs at high speed since the CPU is being used
The problem is clear in the get_times function in cpuspeed.cc. The
last lines of that function convert the variables user_time,
nice_time, system_time, and idle_time, obtained from the kernel, into
the output of the function, total_elapsed and idle_elapsed, in the
261 // count nice time as idle time
262 idle_time += nice_time;
264 total_time = user_time + system_time + idle_time;
265 total_elapsed = total_time - last_total_time;
266 last_total_time = total_time;
267 idle_elapsed = idle_time - last_idle_time;
268 last_idle_time = idle_time;
I think that lines 261-262 should be removed and line 264 should
include nice_type as well.
Created attachment 103744 [details]
I am not sure how should cpuspeed react to niced jobs. Ignoring them
was actually the author's (Carl Thompson) choice (as found in FEATURES):
* "nice()'d" processes will not increase CPU speed
I agree with David that a background niced "make" should increase the
CPU freq. On the other hand, one can argue that a long overnight job
should not heat so much the CPU and make the laptop CPU fan noisy.
I think about two possible solutions:
1. Simple, as David proposes, but controlled by an option (like -nice)
2. More complicated: niced jobs would speed up the CPU but not to the
maximum freq (say one step below the max).
Created attachment 111209 [details]
Adds -n option to include nice time
Similar issue with FC3... I run mythtv on this box the transcode jobs are niced
so that they don't interfere with regular usage (but see how long it takes to
reencode mpeg4 at your lowest cpuspeed if you're doing absolutely nothing on
the machine at hte time :)
Some of the things Michal suggested are not so easy to code so I took the
simplest route that I hoped would be acceptable upstream and added a "-n"
option (they seem to be fond of one letter options so I went with it) that
defaults to off but, if included on the command line, will include nice time in
Patch attached (intended to be applied after the smp patch included in fc3
kernel-utils package so you may have to tweak if you want it in fc2, I don't
Please push upstream as this would be a useful option to some people...
Any chance of integrating the patch in comment #3? It would be very useful to
me as well.
it needs rediffing against 1.2.1
Created attachment 112772 [details]
This is Thomas Walker's patch, heavily modified to apply cleanly in the latest
version of the package. I've tested it on AMD64. I switched -n on by default,
since I believe cpuspeed is far more useful this way, but I wouldn't mind too
much if that bit of the patch was dropped.
*** Bug 176775 has been marked as a duplicate of this bug. ***