'htop' does not show the correct CPU%, but 'top' does
While running mencoder
with threads=4 (on a quad-core cpu). I've noticed that htop
does not show its true CPU usage, but top
does.
It seems that htop is only reporting on one core. Is this a bug/limitation of htop? What is going on here?
There are no other entries for mencoder show up in ps
or htop
or top
. I assume that 100% means that 1 core is maxed out, but even this seems odd to me; what about the other cores?
Update: added "System Monitor" output
PID %CPU COMMAND
"top" 1869 220 mencoder
"htop" 1869 95 mencoder -noodml /media/...
"System Monitor" 1869 220 mencoder
As you've said yourself, you can hit H to show user threads.
Just for future reference (and for fun), let's calculate CPU utilisation!
A bit of background:
In a modern operating system, there's a Scheduler. It aims to ensure that all of the Processes and their threads get a fair share of computing time. I won't go into scheduling too much (it's really complicated). But in the end there is something called a run queue. This is where all the instructions of all of the processes line up to wait for their turn to be executed.
Any process puts it's "tasks" on the run queue, and once the processor's ready, it pops them off and executes them. When a program goes to sleep, for example, it removes itself from the run queue and returns to the "end of the line" once it's ready to run again.
Sorting on this queue has to do with the processes' Priority (also called "nice value" - i.e. a process is nice about system resources).
The length of the queue determines the Load of the system. A load of 2.5 for example means that there are 2.5 instructions for every instruction the CPU can deal with in real time.
On Linux, by the way, this load is calculated in 10ms intervals (by default).
Now onto the Percentage values of CPU utilisation:
Imagine you have two clocks, one is called t
and it represents real time. It measures a second for every second. The other clock we call c
. It only runs if there is processing to do. That means, only when a process calculates something does the clock run. This is also called CPU time. Each and every process on the system 'has got' one of those.
The processor utilisation can now be calculated for a single process:
or for all processes:
On a multi core machine, this may result in a value of 3.9 of course, because the CPU can calculate four seconds worth of computation every second, if utilised perfectly.
Wikipedia provides this example:
A software application running in 6-CPU UNIX machine creates three UNIX processes for fulfilling the user requirement. Each of these three processes create two threads. Work of software application is evenly distributed on 6 independent threads of execution created for the application. If no wait for resources is involved, Total CPU time is expected to be six times Elapsed real time.
Here's a small python snippet that does this
>>> import time
>>> t = time.time()
>>> c = time.clock()
>>> # the next line will take a while to compute
>>> tuple(tuple(i**0.2 for i in range(600)) for i in range(6000))
>>> print (time.clock() / (time.time() - t)) * 100, "%"
66.9384021612 %
In a perfect world, you could infer from this that system load is 100 - 66.93 = 33,1%. (But in reality that'd be wrong because of complex things like I/O wait, scheduling inefficiencies and so on)
In contrast to load, these calculations will always result in a value between 0 and the number of processors, i.e. between 0 and 1 or 0 to 100%. There is now no way to differentiate between a machine that is running three tasks, utilising 100% cpu, and a machine running a million tasks, getting barely any work done on any single one of them, also at 100%. If you're, for instance, trying to balance a bunch of processes on many computers, cpu utilisation is next to useless. Load is what you want there.
Now in reality, there is more than one of those processing time clocks. There's one for waiting on I/O for example. So you could also calculate I/O resource utilisation.
This may not have been helpful regarding the original question, but I hope it's interesting. :)