Bug 132383

Summary: cpuspeed should not count nice time as idle time (niced compiles don't raise CPU speed)
Product: [Fedora] Fedora Reporter: David Baron <dbaron>
Component: cpuspeedAssignee: Dave Jones <davej>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mitr, msz, oliva, pfrields
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: cpuspeed-1.2.1-1.20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-26 21:29:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed patch
none
Adds -n option to include nice time
none
rediffed/updated patch none

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):
  kernel-utils-2.4-9.1.131

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;
263
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
know).

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