8000 100% load for singe CPU core · Issue #202 · hishamhm/htop · GitHub
[go: up one dir, main page]
Skip to content
This repository was archived by the owner on Sep 8, 2020. It is now read-only.
This repository was archived by the owner on Sep 8, 2020. It is now read-only.

100% load for singe CPU core #202

Closed
Closed
100% load for singe CPU core#202

Description

@poiuty
poiuty
opened on Jun 3, 2015

Hello, my favorite toolkit author! I have found very strange issue with htop (1.0.3). Sometimes it show 100% load for singe CPU core. But actually I checked CPU consumption with mpstat and top in same time and haven't saw any 100% consumption for any CPU. Could you check this?

Also htop 1.0.1 not show this => https://poiuty.com/img/45bf0370d934efecd40a41156509.png
Debian 8, 3.16.0-4-amd64

Activity

  3. hishamhm commented on Aug 19, 2015

    @hishamhm
    hishamhm
    on Aug 19, 2015
    Owner

    @poiuty, thanks for the bug report!
    @kerframil, thanks for the bisect analysis!

    What kernel version are you guys running?

  4. poiuty commented on Aug 19, 2015

    @poiuty
    poiuty
    on Aug 19, 2015
    Author

    3.16.0-4-amd64 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux

  5. hishamhm commented on Aug 19, 2015

    @hishamhm
    hishamhm
    on Aug 19, 2015
    Owner

    I had no success yet in tracking what could cause problems with af285d1... I just sent an email to Patrick Marlier, the patch author, hopefully he can help!

  6. maskur commented on Aug 20, 2015

    @maskur
    maskur
    on Aug 20, 2015

    Patrick Marlier and I looked into this bug report, but I am not sure we fully understood the problem. Could you please provide a scenario to reproduce the wrong behavior (what workloads are running in the VM, what is the configuration of the VM,...)? Thanks!

  7. poiuty commented on Aug 20, 2015

    @poiuty
    poiuty
    on Aug 20, 2015
    Author

    all pkg from from apt-get repo debian 8
    install htop, kvm-qemu, virsh, libvirt
    create debian vm and install LAMP server with low load (0~20%)

    open htop (node) => sometimes we see 100%
    open htop (vm) => no 100%
    open top (node) => no 100%

    Also, when we see 100% => no process => who use this cpu
    https://poiuty.com/img/ba882296d303b83e88ceb9ee8643.png

  8. maskur commented on Aug 20, 2015

    @maskur
    maskur
    on Aug 20, 2015

    Thank you. We were able to reproduce the problem. There seems to be a overflow problem, when updating the cpuData->userPeriod (ProcessList.c, line 969). We are not sure yet where this is coming from, but a temporary fix could be

    cpuData->userPeriod = usertime - cpuData->userTime;
    ----->
    cpuData->userPeriod = usertime+1 - cpuData->userTime;

    since usertime is only slightly smaller than cpuData->userTime.

  9. milosivanovic commented on Aug 24, 2015

    @milosivanovic
    milosivanovic
    on Aug 24, 2015

    I'd just like to chip in and say that I too noticed this when htop 1.0.3 was released but didn't have the time to look into it; instead, I just stayed on htop 1.0.2.

    The proposed workaround does work as described, but it will be adding usertime that was never there in the first place, resulting in false readings (a very slight increase of what the actual processor usage will be at any given moment). This is most noticeable with an idle system.

    I'm unsure if @kerframil's report is related to this bug, which remains even with the workaround implemented (hence the thought that it probably isn't related). @kerframil is talking about all cores displaying 100% usage when htop is first invoked, until the next delta cycles in, whereas this bug report is talking about displaying 100% usage for a single core randomly while htop is running.

    I have confirmed both bugs as of 8f07868, but a new issue should be opened for what @kerframil is reporting unless I am somehow mistaken.

  12. patrickmarlier commented on Aug 24, 2015

    @patrickmarlier
    patrickmarlier
    on Aug 24, 2015
    Contributor

    I checked a bit the kernel source and I don't really explain why the user time stays the same while the guest time increases. Indeed, in the kernel, it adds the guest time to user time so it could be a rounding effect due to cputime64_to_clock_t?
    Hisham any advice on how we could fix this? One possibility is to remove the assert for usertime and nicetime and instead if overflow to put it to 0.

  13. patrickmarlier commented on Aug 28, 2015

    @patrickmarlier
    patrickmarlier
    on Aug 28, 2015
    Contributor

    Here I see 2 issues (kernel 4.1.6):

    kernel/sched/cputime.c:account_guest_time()

    cpustat[CPUTIME_USER] += (__force u64) cputime;
    cpustat[CPUTIME_GUEST] += (__force u64) cputime;

    There is no synchronization in the cpustat data-structure. One example is if one thread is reading the 2 values while one thread has only updated the fisrt value yet. This is unlikely but I think this can happen.

    fs/proc/stat.c:show_stat()

    seq_put_decimal_ull(p, ' ', cputime64_to_clock_t(user));

    cputime64_to_clock_t() convert types and this rounding is probably the problem we are seeing.
    Example:

                   cputime64 -> clock_t
   user:     41892000000 -> 4189
   guest:    37788000000 -> 3778

    The difference with the output of /proc/stat, we get 411. However if you do the same using, cputime64 in the kernel, you will get 4104000000 that is closer to 410 than 411. So finally if you take values at 2 different time, you cannot be sure about the rounding and led to this possible difference of 1.

    Opinions on how to fix? I propose to remove the assert and check for overflows but I am open to all possible fix.

  14. hishamhm commented on Aug 28, 2015

    @hishamhm
    hishamhm
    on Aug 28, 2015
    Owner

    Hisham any advice on how we could fix this? One possibility is to remove the assert for usertime and nicetime and instead if overflow to put it to 0.

    If it all comes down to a rounding glitch that leaks from the kernel, then I think this is the most sensible approach. Thank you @maskur and @patrickmarlier for the amazing hunter work!

    (@kerframil @milosivanovic, yes, I believe the incorrect values in the first iteration is due to a different problem, so this should probably be a separate bug entry.)

  15. patrickmarlier commented on Sep 14, 2015

    @patrickmarlier
    patrickmarlier
    on Sep 14, 2015
    Contributor

    If somebody can give it a try, I am proposing a fix. See branch issue202 in my htop fork.
    Thanks.

  16. poiuty commented on Oct 25, 2015

    @poiuty
    poiuty
    on Oct 25, 2015
    Author

    @patrickmarlier, no it`s not help.

  17. poiuty commented on Oct 25, 2015

    @poiuty
    poiuty
    on Oct 25, 2015
    Author

    Sorry, my bad (test main branch).
    re-test => issue202 work nice => no 100%

  18. hishamhm
    closed this as completedin #298on Oct 26, 2015
  19. hishamhm
    added a commit that references this issue on Oct 26, 2015

    Merge pull request #298 from patrickmarlier/issue202

    b669540

  20. hishamhm commented on Oct 26, 2015

    @hishamhm
    hishamhm
    on Oct 26, 2015
    Owner

    Merged! Thanks @patrickmarlier!

  21. hishamhm commented on Oct 26, 2015

    @hishamhm
    hishamhm
    on Oct 26, 2015
    Owner

    Thank you @poiuty for testing!

  22. Rovanion
    added a commit that references this issue on Apr 12, 2016

    htoprc - If it ever comes up, don't count VM guests.

    2db34cc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      0