Don't you have colors?
Green Blue Orange
Mem[|||||||||||||||||||||||||||||||||||||||||||| 1978/7847MB]
Where green should be 1978 MiB.
Else you can enter F2 -> Under setup stay on "Meters" -> Right arrow to get to "Left column". -> Down 1 to get to "Memory Bar".
Then press enter to view various ways of display.
When it comes to what the bar displays it is like this.
It reads /proc/meminfo and show - colors depend on "Colors" setting - this is default:
Used U (green): (MemTotal - MemFree) - (Buffers + Cached) / 1024
And then the percentage of MemTotal of that.
Bar:
Green Blue Orange/Yellow
[Used U % of total | Buffers % of total | Cached % of total ] Used U / Toatal MB
Also see here.
I have a script some where that makes it as well. Have to look for it.
You're seeing a side effect of the program seeing its loading resource usage. Loading an executable and its libraries into memory, initializing and turning control over to program is not a free operation: it involves the CPU, memory and (if it hasn't been cached) disk.
Here's top showing its usage immediately upon starting:
top - 13:21:29 up 1 day, 23:31, 1 user, load average: 1.73, 1.78, 1.46
Tasks: 151 total, 3 running, 93 sleeping, 0 stopped, 0 zombie
%Cpu(s): 16.4 us, 5.7 sy, 0.0 ni, 73.1 id, 4.6 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 3967564 total, 135908 free, 2053480 used, 1778176 buff/cache
KiB Swap: 8388604 total, 8332796 free, 55808 used. 1652564 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
896 qemu 20 0 1961872 508076 6144 S 100.0 12.8 790:22.87 /usr/bin/qemu-system-x86_64 -name guest=Gentoo-amd64,debug-threads=on +
596 qemu 20 0 2326244 863164 4488 R 6.2 21.8 311:23.29 /usr/bin/qemu-system-x86_64 -name guest=data,debug-threads=on -S -obje+
12655 root 20 0 49732 4164 3432 R 6.2 0.1 0:00.01 top -d 10
1 root 20 0 49568 5492 3700 S 0.0 0.1 0:02.52 /lib/systemd/systemd --switched-root --system --deserialize 32
After 10 seconds (it's the same for smaller periods, but I wanted to be able to copy the text at startup):
896 qemu 20 0 1961872 508076 6144 R 103.5 12.8 790:33.23 /usr/bin/qemu-system-x86_64 -name guest=Gentoo-amd64,debug-threads=on +
596 qemu 20 0 2326244 863164 4488 R 8.7 21.8 311:24.16 /usr/bin/qemu-system-x86_64 -name guest=data,debug-threads=on -S -obje+
10200 root 20 0 1354396 131740 29824 S 3.1 3.3 13:05.97 python2.7 /usr/share/virt-manager/virt-manager
10150 root 20 0 66548 6004 4880 S 2.6 0.2 8:22.49 sshd: root@pts/0
850 qemu 20 0 1726656 300432 5496 S 0.8 7.6 19:30.70 /usr/bin/qemu-system-x86_64 -name guest=distcc-i686,debug-threads=on -+
328 avahi 20 0 53744 3608 2936 S 0.2 0.1 0:10.93 avahi-daemon: running [server-calgary.local]
460 root 20 0 0 0 0 S 0.1 0.0 0:04.87 [nfsd]
475 root 20 0 1282444 13820 8268 S 0.1 0.3 1:13.16 /usr/sbin/libvirtd --listen
9143 root 20 0 0 0 0 I 0.1 0.0 0:36.05 [kworker/1:1]
10146 root 20 0 0 0 0 I 0.1 0.0 0:25.93 [kworker/0:2]
12641 root 20 0 0 0 0 I 0.1 0.0 0:00.02 [kworker/u4:0]
12655 root 20 0 49732 4176 3432 R 0.1 0.1 0:00.02 top -d 10
1 root 20 0 49568 5492 3700 S 0.0 0.1 0:02.52 /lib/systemd/systemd --switched-root --system --deserialize 32
Does top really use 6.2% of the CPU to do its work? No: that's the loading work that all programs will have at startup. Usage goes down to 0.1% after the program has settled down.
It's unlikely that htop is using 100% of a CPU (there's possibly a bug there), but it's not strange that it has higher usage when starting either.
Best Answer
Over time, the operating system schedules threads on different CPU cores, so the 101% reported for your processes are potentially distributed over all 8 bars.