Unexpected HTOP results – RAM usage increases more running termit than konsole

[CloisteredNeuron]

Below are the results of running HTOP first in KONSOLE and second in TERMIT. Note the Uptime values. My goal was to identify a light weight terminal using HTOP, and TERMIT looked promising. Indeed, the RES of KONSOLE was 130M vs 56K for TERMIT. Very interestingly the HTOP Mem actually increased from running HTOP in KONSOLE to running HTOP in TERMIT. Note that I stopped HTOP in KONSOLE and closed KONSOLE before starting TERMIT and running HTOP in it. As the RES of KONSOLE is more than twice the size of TERMIT, I would expect that HTOP Mem would go down and not up like it did - 657M with KONSOLE and 667M with TERMIT. FEATHERPAD and each terminal were the only apps I manually started during this testing.

The results were so unexpected I rebooted the system twice and started HTOP in TERMIT after the first reboot and KONSOLE after the second reboot. TERMIT with a RES of 55.5M had an HTOP Mem of 626M vs KONSOLE with a RES of 137M and an HTOP Mem of 554M. Results below the ******* line. KONSOLE consumes 626M-554M = 72M LESS HTOP Mem than TERMIT based upon these results.

Anyone know why KONSOLE would use less HTOP Mem?

The system is Debian 12.5 Stable (bookworm) running plasma-desktop (KDE) on wayland.

And one more set of results, below the second ******* line. In this case an HTOP Mem reading of 553M was taken at 2 minutes after reboot. Thirty seconds later after starting SPEEDCRUNCH, calculator, an HTOP Mem reading of 634M was recorded. SPEEDCRUNCH has a RES of 122M yet HTOP Mem only increases by 634M-553M = 81M.

Again, I find myself unable to make sense of how HTOP Mem does not increase at least the same amount of the HTOP RES of newly started apps.

Thanks!

KONSOLE
0[|| 1.0%] Tasks: 51, 94 thr, 62 kthr; 1 running
1[|| 0.8%] Load average: 0.06 0.12 0.15
Mem[|||||||||||||||||||||||| 657M/3.82G] Uptime: 00:40:46
Swp[ 0K/975M]

[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1910 cloy 20 0 560M 130M 104M S 0.2 3.3 0:01.74 /usr/bin/konsole
1918 cloy 20 0 558M 126M 101M S 0.0 3.2 0:00.59 /usr/bin/featherpad

TERMIT
0[|| 0.8%] Tasks: 51, 94 thr, 62 kthr; 2 running
1[|| 1.0%] Load average: 0.20 0.15 0.16
Mem[||||||||||||||||||||||||| 667M/3.82G] Uptime: 00:42:26
Swp[ 0K/975M]

[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1918 cloy 20 0 560M 128M 103M S 0.0 3.3 0:01.06 /usr/bin/featherpad
1928 cloy 20 0 678M 56032 42552 S 0.0 1.4 0:00.86 /usr/bin/termit

---

TERMIT at 2 minutes of uptime after reboot.
0[| 0.6%] Tasks: 53, 96 thr, 69 kthr; 1 running
1[|| 0.4%] Load average: 0.30 0.20 0.08
Mem[|||||||||||||||||||||||| 626M/3.82G] Uptime: 00:02:01
Swp[ 0K/975M]

[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1647 cloy 20 0 637M 133M 108M S 0.0 3.4 0:01.13 /usr/bin/featherpad
1607 cloy 20 0 614M 55528 42472 S 0.0 1.4 0:00.88 /usr/bin/termit

KONSOLE at 2 minutes of uptime after rebooting after TERMIT 2 minute test.
0[||||| 5.1%] Tasks: 50, 90 thr, 69 kthr; 2 running
1[||||| 5.2%] Load average: 0.14 0.12 0.05
Mem[||||||||||||||||||||| 554M/3.82G] Uptime: 00:02:07
Swp[ 0K/975M]

[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1601 cloy 20 0 567M 137M 111M S 3.2 3.5 0:01.61 /usr/bin/konsole
1611 cloy 20 0 637M 133M 108M S 0.0 3.4 0:00.66 /usr/bin/featherpad

---

KONSOLE
0[|| 0.6%] Tasks: 49, 90 thr, 72 kthr; 1 running
1[ 0.0%] Load average: 0.08 0.07 0.02
Mem[||||||||||||||||||||| 553M/3.82G] Uptime: 00:02:04
Swp[ 0K/975M]

[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1477 cloy 20 0 1519M 243M 140M S 0.6 6.2 0:02.95 /usr/bin/plasmashell --no-respawn
1435 cloy 20 0 741M 171M 130M S 0.2 4.4 0:01.79 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-disp
1613 cloy 20 0 637M 135M 109M S 0.0 3.5 0:00.73 /usr/bin/featherpad
1601 cloy 20 0 564M 133M 107M S 0.0 3.4 0:00.79 /usr/bin/konsole

KONSOLE with SPEEDCRUNCH
0[|| 0.6%] Tasks: 50, 98 thr, 72 kthr; 1 running
1[|| 1.0%] Load average: 0.11 0.07 0.03
Mem[||||||||||||||||||||||| 634M/3.82G] Uptime: 00:02:34
Swp[ 0K/975M]

[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1477 cloy 20 0 1613M 254M 141M S 0.2 6.5 0:03.59 /usr/bin/plasmashell --no-respawn
1435 cloy 20 0 746M 177M 133M S 0.4 4.5 0:02.65 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-disp
1613 cloy 20 0 637M 136M 109M S 0.0 3.5 0:00.91 /usr/bin/featherpad
1601 cloy 20 0 564M 133M 107M S 0.2 3.4 0:01.03 /usr/bin/konsole
1625 cloy 20 0 694M 122M 95144 S 0.0 3.1 0:00.38 /usr/bin/speedcrunch

[BenBE]

The RES column loosly speaking shows the "private working set" of an application and as such is not affected by other applications being started. There's also the SHARED column which tracks how much memory is shared between different processes. This column somewhat follows the LIBS column, which displays the amount of memory occupied by shared libraries (executable segments).

When starting a new process, not all of its libraries need to be loaded afresh as most of them are already loaded by another process. After all that's why libraries were built in the first place. Thus counter-intuitively it may be more beneficial to run an application with a larger library footprint like konsole over a more efficient tool such as termit, if most of your processes already load the libraries that konsole needs anyway.

[CloisteredNeuron]

I was thinking that konsole, being the default KDE terminal, could be taking advantage of components shared by KDE apps. Konsole's SHR value of 115M caught my attention. Would it make sense to assume the memory consumed by starting konsole is RES - SHR (143M - 115M = 28M for konsole "if" other KDE apps had already loaded all of konsole's shared libraries - SHR)?

HTOP
0[|| 1.4%] Tasks: 50, 86 thr, 61 kthr; 1 running
1[| 0.2%] Load average: 0.10 0.09 0.08
Mem[||||||||||||||||||||||| 569M/3.82G] Uptime: 01:12:07
Swp[ 0K/975M]
[Main] [I/O]
PID USER PRI NI VIRT RES▽ SHR S CPU% MEM% TIME+ Command
1475 user 20 0 1526M 252M 141M S 0.4 6.5 0:23.18 /usr/bin/plasmashell --no-respawn
1431 user 20 0 821M 177M 128M S 0.0 4.5 0:25.99 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-disp
1603 user 20 0 901M 143M 115M S 0.0 3.7 0:21.12 /usr/bin/konsole

I googled "private wokring set" and found it was associated with "Resident Set Size", RSS. ps -aux --sort -rss includes RSS. The size of the ps RSS and HTOP RES are similar for konsole. Is the HTOP RES field based on the same data source as ps's RSS?

$ ps -aux --sort -rss
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
user 1475 0.5 6.4 1562616 258836 ? Ssl Jun15 0:22 /usr/bin/plasmashell --no-respawn
user 1431 0.5 4.5 841224 182172 ? Sl Jun15 0:24 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-disp
user 1603 0.4 3.6 923076 146552 ? Sl Jun15 0:20 /usr/bin/konsole

Thanks BenBE!

[BenBE]

I was thinking that konsole, being the default KDE terminal, could be taking advantage of components shared by KDE apps. Konsole's SHR value of 115M caught my attention. Would it make sense to assume the memory consumed by starting konsole is RES - SHR (143M - 115M = 28M for konsole "if" other KDE apps had already loaded all of konsole's shared libraries - SHR)?

The SHR value does not really show how much is shared, but rather how much is marked as shareable. Thus if it says 100MiB to be shared, then there's 100MiB that the kernel could share with other processes, not that there also is another process for each of the associated pages too. The RES column mostly is about private data for the process, think malloc and such.

I googled "private wokring set" and found it was associated with "Resident Set Size", RSS. ps -aux --sort -rss includes RSS. The size of the ps RSS and HTOP RES are similar for konsole. Is the HTOP RES field based on the same data source as ps's RSS?

Without looking into the source, AFAIR yes. That should be the same value from the information provided by the procfs …

Thanks BenBE!

[CloisteredNeuron]

Very good. Thanks so much BenBE!!