Bug 132383 - cpuspeed should not count nice time as idle time (niced compiles don't raise CPU speed)
Summary: cpuspeed should not count nice time as idle time (niced compiles don't raise ...
Alias: None
Product: Fedora
Classification: Fedora
Component: cpuspeed (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Keywords: Patch
: 176775 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-12 01:44 UTC by David Baron
Modified: 2015-01-04 22:09 UTC (History)
4 users (show)

Fixed In Version: cpuspeed-1.2.1-1.20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-26 21:29:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (1.01 KB, patch)
2004-09-12 01:56 UTC, David Baron
no flags Details | Diff
Adds -n option to include nice time (3.06 KB, patch)
2005-02-18 16:22 UTC, Thomas Walker
no flags Details | Diff
rediffed/updated patch (1.89 KB, patch)
2005-04-06 18:27 UTC, Alexandre Oliva
no flags Details | Diff

Description David Baron 2004-09-12 01:44:21 UTC
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
near 100%.

Additional info:

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
following manner:

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.

Comment 1 David Baron 2004-09-12 01:56:26 UTC
Created attachment 103744 [details]
proposed patch

Comment 2 Michal Szymanski 2004-09-28 10:52:10 UTC
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).

regards, Michal.

Comment 3 Thomas Walker 2005-02-18 16:22:50 UTC
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
cpuspeed's calculations.

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...

Comment 4 Alexandre Oliva 2005-03-18 09:03:05 UTC
Any chance of integrating the patch in comment #3?  It would be very useful to
me as well.

Comment 5 Dave Jones 2005-03-18 17:42:44 UTC
it needs rediffing against 1.2.1

Comment 6 Alexandre Oliva 2005-04-06 18:27:02 UTC
Created attachment 112772 [details]
rediffed/updated patch

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.

Comment 7 Michal Szymanski 2006-01-02 11:26:41 UTC
*** Bug 176775 has been marked as a duplicate of this bug. ***

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