I just installed screenlets to get some onscreen information about my system. I'm trying the RingSensors screenlet to monitor cpu load, but there are more sensors available to monitor than I'd expect.
When I go to the settings to select which cpu (core) the ring should monitor I get 5 different cpus to choose from:
My processor is a QuadCore so I'd expect 4 CPU monitors, not 5. If I check /proc/cpuinfo I get the expected count:
$ cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 3
All the monitors get some kind of reading since they present a ever updating value:
Both htop and RingSensors have some update interval, so even though I had both meters on the screen simultaneously when I did the screencap I'm not surprised that htop and ringsensors get different values.
Can someone explain the extra cpu meter to me?
Is one of the meters the average load of all the cores or something?
Is there some way I can try to max out one core at a time to see how that affects the reported load values?
EDIT:
Using the command taskset combined with the command stress I was able to stress one core at a time and from that I could derive that CPU1-4 represent the individual cores, and CPU0 is something else, the aggregation of half of the cores or something.
$ stress -c 1&
[1] 18829
$ taskset -p -c 0 18830
pid 18830's current affinity list: 0-3
pid 18830's new affinity list: 0
$ taskset -p -c 1 18830
pid 18830's current affinity list: 0
pid 18830's new affinity list: 1
$ taskset -p -c 2 18830
pid 18830's current affinity list: 1
pid 18830's new affinity list: 2
$ taskset -p -c 3 18830
pid 18830's current affinity list: 2
pid 18830's new affinity list: 3
As you can see stress spawned a child process, that's why I must set the affinity of the pid 18830 instead of 18829.
Lastly, if I max out two (or more) cores simultaneously I get CPU0 to max out aswell:
