lkml.org 
[lkml]   [2010]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: High CPU load when machine is idle (related to PROBLEM: Unusually high load average when idle in 2.6.35, 2.6.35.1 and later)
    On Tue, Nov 30, 2010 at 03:59:05PM +0100, Peter Zijlstra wrote:
    > On Tue, 2010-11-30 at 00:01 +0100, Peter Zijlstra wrote:
    > >
    > > Ok, that's good testing.. so its still not quite the same as NO_HZ=n,
    > > how about this one?
    > >
    > > (it seems to drop down to 0.00 if I wait a few minutes with top -d5)
    >
    > OK, so here's a less crufty patch that gets the same result on my
    > machine, load drops down to 0.00 after a while.
    >
    > It seems a bit slower to reach 0.00, but that could be because I
    > actually changed the load computation for NO_HZ=n as well, I added a
    > rounding factor in calc_load(), we no longer truncate the division.
    >
    > If people want to compare, simply remove the third line from
    > calc_load(): load += 1UL << (FSHIFT - 1), to restore the old behaviour.

    For some bizzare reason, this version has a small but noticable amount of
    jitter and never really seems to hit 0.00 on my machine, tends to jump
    around at low values between 0.03 to 0.08 on a routine basis:

    16:20:42 up 16:31, 4 users, load average: 0.00, 0.01, 0.05

    the jitter seems to have no visible reason for it happening; with no
    networking, disk access or a process waking up and demanding attention from
    the cpu, it goes back up.

    Mind this is obviously NOT as horrible as it was originally, but I'd like to
    find out why it's acting so differently.

    I'm going to try this variant again with that line you were talking about
    disabled and see if it reacts differently. I get the feeling if it's the
    rounding factor - since you say that was changed for BOTH nohz=y and n, that
    it's not really a problem in the first place, and likely is very low load
    that wasn't being accurately reported before.


    Tim McGrath[unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2010-12-01 22:29    [W:7.632 / U:0.656 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site