Tracker: Bugs

5 htop does not work correctly with BFS patched kernel - ID: 3511139
Last Update: Comment added ( loderunner )

Htop gets all messed up on kernels patched with Con Kolivas' BFS. Htop doesn't display the CPU% correctly. Attached is a screenshot showing my system compiling on a quad core CPU. The CPU progress bars at the top are correct, but the table display is not: gcc is using all the cores.

Link to BFS: http://ck.kolivas.org/patches/bfs/3.3.0/3.3-sched-bfs-420.patch

$ htop --version
htop 1.0.1 - (C) 2004-2011 Hisham Muhammad
Released under the GNU GPL.


John A. ( graysky ) - 2012-03-25 16:29:21 PDT

5

Closed

Postponed

Nobody/Anonymous

Interface (example)

v1.0 (example)

Public


Comment ( 1 )




Date: 2012-03-26 10:47:32 PDT
Sender: loderunnerProject Admin

Hi, sorry about not having responded your earlier email.

I have received this report in the past as well, and the conclusion is that
some behavior in BFS is strange. Here's the relevant parts of the email
exchange:

"""Hisham, hi!

Can you, please, comment the issue presented in this (started by me) Arch
Linux thread?

https://bbs.archlinux.org/viewtopic.php?id=129410

I have contacted with Con Kolivas, but now he hasn't a time frame to dig
in
the htop code to find those differences in ways top and htop gather CPU
information."""

"""Hi,

Given that, as you say, meters are consistent under official Linux
kernels and the problem presents itself not only with htop but also
KSysGuard only in linux-ck kernels, that would make us think the
problem is actually in linux-ck, right?

I also noticed that in this screenshot...
http://gaydenko.com/tmp/top-01.png
...the process in 'top' shows "336" in CPU but the "Cpus" meter in the
header says "1.6%us, 98.4%id" (much like htop's meters). I may be
mistaken, but it looks like not even 'top' is getting its calculations
right under linux-ck.

To help debug the issue, this is what I do to calculate CPU values in
htop:

--------------------------
Meters:
For each screen update, I read /proc/stat to get user, nice, system,
idle and virt time for each CPU. I sum those and get "total time". I
subtract the current total time from the previous total time and get
the "total period". Each percentage that shows in the meters is done
like this:

for X in user, nice, system, idle, virt:
Xpercentage = ((currentX - previousX) / totalPeriod * 100)

For processes:
First I calculate the "CPU period" value: totalPeriod / numberOfCpus.
Then, for each process, I read utime and stime from their
/proc/<pid>/stat file. Then I do this:
CPU = (utime+stime-prevUtime-prevStime) / cpuPeriod * 100
--------------------------

Perhaps with this information Con Kolivas can shed some light on why
these calculations work on standard kernels but not on his.

Hope this helps!!

Cheers,

-- Hisham"""

"""Hisham,

Tanks for quick and elaborated answer! I'll include the fragment separated
with '-' (as well as your note about Cpu(s) string) into a message to Con.

Andrew"""

My position on the matter is still the same, so for the time being I am not
treating this as a bug in htop. If you get a response from Con Kolivas on
the matter, I'll be able to try to take another look at this and possibly
come up with a workaround, if the problem is really on this end. Thank
you!!


Log in to comment.

Attached File ( 1 )

Filename Description Download
htop.png screenshot of htop Download

Changes ( 4 )

Field Old Value Date By
status_id Open 2012-03-26 10:47:32 PDT loderunner
resolution_id None 2012-03-26 10:47:32 PDT loderunner
close_date - 2012-03-26 10:47:32 PDT loderunner
File Added 439348: htop.png 2012-03-25 16:29:22 PDT graysky