Why Arch Linux KDE still uses RAM after closing?

bivan · Yesterday 15:12:40

I start Arch Linux KDE, RAM used: 1.4 GiB, according to System Monitor.
Then e.g. I use Chromium, Steam, then I close all: 2.0 GiB, why not 1.4 GiB as before? What is the remaining 0.6 GiB?

seth · Yesterday 15:29:14

Probably the file cache - those RAM usage aggregators look fancy on r/unixporn but are completely useless for any meaningful insight.
Compare

cat /proc/meminfo

"free -h" at least separates the cache

bivan · Yesterday 15:59:43

At start:

[a@f44101f2-e4b3-4b62-9eed-a988c75d2c02 ~]$ free -h
cat /proc/meminfo
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.3Gi        29Gi        17Mi       762Mi        29Gi
Swap:           15Gi          0B        15Gi
MemTotal:       32777324 kB
MemFree:        31119604 kB
MemAvailable:   31449564 kB
Buffers:            1584 kB
Cached:           736740 kB
SwapCached:            0 kB
Active:           935924 kB
Inactive:         182848 kB
Active(anon):     444960 kB
Inactive(anon):        0 kB
Active(file):     490964 kB
Inactive(file):   182848 kB
Unevictable:       46928 kB
Mlocked:               0 kB
SwapTotal:      16777212 kB
SwapFree:       16777212 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:                76 kB
Writeback:             0 kB
AnonPages:        427376 kB
Mapped:           396632 kB
Shmem:             17708 kB
KReclaimable:      42504 kB
Slab:             122724 kB
SReclaimable:      42504 kB
SUnreclaim:        80220 kB
KernelStack:        7488 kB
PageTables:        12528 kB
SecPageTables:      2892 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    33165872 kB
Committed_AS:    2226368 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      126096 kB
VmallocChunk:          0 kB
Percpu:            13248 kB
HardwareCorrupted:     0 kB
AnonHugePages:    135168 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
Unaccepted:            0 kB
Balloon:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      360480 kB
DirectMap2M:     5851136 kB
DirectMap1G:    27262976 kB

then Chromium, Steam, then close all:

[a@f44101f2-e4b3-4b62-9eed-a988c75d2c02 ~]$ free -h
cat /proc/meminfo
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.5Gi        27Gi        22Mi       2.4Gi        29Gi
Swap:           15Gi          0B        15Gi
MemTotal:       32777324 kB
MemFree:        29246296 kB
MemAvailable:   31229268 kB
Buffers:            1584 kB
Cached:          2354048 kB
SwapCached:            0 kB
Active:          2297324 kB
Inactive:         511344 kB
Active(anon):     522616 kB
Inactive(anon):        0 kB
Active(file):    1774708 kB
Inactive(file):   511344 kB
Unevictable:       46928 kB
Mlocked:               0 kB
SwapTotal:      16777212 kB
SwapFree:       16777212 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        498668 kB
Mapped:           420956 kB
Shmem:             22780 kB
KReclaimable:     124044 kB
Slab:             228244 kB
SReclaimable:     124044 kB
SUnreclaim:       104200 kB
KernelStack:        7008 kB
PageTables:        13296 kB
SecPageTables:      3324 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    33165872 kB
Committed_AS:    2439436 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      126116 kB
VmallocChunk:          0 kB
Percpu:            13824 kB
HardwareCorrupted:     0 kB
AnonHugePages:    188416 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
Unaccepted:            0 kB
Balloon:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      716832 kB
DirectMap2M:    10737664 kB
DirectMap1G:    22020096 kB

indeed Cached: increased, so it's https://en.wikipedia.org/wiki/Page_cache https://www.linuxatemyram.com/ ?
Now, maybe I should create a new topic? How to disable the page cache? Googling "arch linux disable page cache": https://unix.stackexchange.com/question … page-cache "It is not possible"...

Last edited by bivan (Yesterday 16:04:49)

mithrial · Yesterday 16:16:27

Why would you need to disable it?

seth · Yesterday 18:25:50

/proc/sys/vm/drop_caches - but you don't want to do that.
The cache exists for a reason (no, the fastestmostexpensive NAND is still 5 times slower than the cheapest RAM you can use) and will opportunistically be surrendered on demand.

bivan · Yesterday 20:18:22

Curiosity, experimentation, ecology (less electricity used by RAM), if seth is right.

Indeed in https://www.linuxatemyram.com/ there's

echo 3 | sudo tee /proc/sys/vm/drop_caches

& https://linux-mm.org/Drop_Caches , so closing Chromium:

[a@c20446b9-8ebc-4cca-a5f5-e5c6e1bbc354 ~]$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       2.0Gi        23Gi        27Mi       6.1Gi        29Gi
Swap:           15Gi          0B        15Gi

then

[a@c20446b9-8ebc-4cca-a5f5-e5c6e1bbc354 ~]$ sync
[a@c20446b9-8ebc-4cca-a5f5-e5c6e1bbc354 ~]$ echo 3 | sudo tee /proc/sys/vm/drop_caches
3
[a@c20446b9-8ebc-4cca-a5f5-e5c6e1bbc354 ~]$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.7Gi        29Gi        10Mi       466Mi        29Gi
Swap:           15Gi          0B        15Gi

still above 1.4 GiB...

seth · Yesterday 20:26:51

ecology (less electricity used by RAM), if seth is right.

Would you please reference where I uttered such nonsense?
As a matter of fact, on average the opposite is true.

still above 1.4 GiB...

You'll have to look at the meminfo, free defining "used" is way to abstract to make any call here.

dimich · Yesterday 20:47:06

bivan wrote:

ecology (less electricity used by RAM)

PASR (Partial Array Self-Refresh) can work only with special types of memory, like LPDDR, and should be supported by hardware. It's highly doubtful that your system can do this.
Regular DRAM consumes the same power regardles of "used" and "free" OS values.

bivan · Yesterday 20:51:33

I replied to mithrial.

seth wrote:

way to abstract

You mean "too" not "to"?

In my post https://bbs.archlinux.org/viewtopic.php … 2#p2303082 it's even 1.3 GiB.

My RAM is DDR4, googling "0 ram same power than 1": https://www.reddit.com/r/explainlikeimf … computers/ , are you sure dimich?

Last edited by bivan (Yesterday 21:03:33)

seth · Yesterday 21:12:44

ecology (less electricity used by RAM), if seth is right.

Not a typo, I deliberately skipped one "O" to save power

And yes, dimich is sure.
And even w/ PASR, having to constantly access/power an SSD would outweigh that - and let's not talk about HDDs, optical drives or remote storage…

it's even 1.3 GiB.

Not sure what that's supposed to say, but you'll have to track /proc/meminfo to monitor the impact of those actions w/ reasonable resolution.
nb. that esp amd seems very generous and greedy wrt GTT and GART, so that might occupy unaccounted memory.

bivan · Yesterday 21:41:00

RAM uses power to constantly refresh a 1, not a 0...

GTT?

I just find bizarre I boot Arch Linux KDE, a used RAM value, I use softwares, I close all, a above used RAM value.

Last edited by bivan (Today 07:26:23)

dimich · Yesterday 22:50:11

bivan wrote:

RAM uses power to constantly refresh a 1, not a 0...

... in true-cells. In anti-cells it's opposite.
Have you measured the difference?

seth · Today 05:10:54

https://en.wikipedia.org/wiki/Graphics_ … ping_table

"Do you have access to the equipment required to measure that?"
https://en.wikipedia.org/wiki/Dynamic_r … ell_design
Regardless of the local cell design, the difference between the two values is a fraction of the base demand to operate the DRAM which is insignificant unless the system is in S3.
Even if the cache would not be more efficient than re-reading the data from wherever it's stored and even if ~1/2 of the used RAM wouldn't be 0-bits anyway (probably more), mentioning "ecology" implies a missing sense of scale - it would be more effective to combat flooding with a tea spoon.

I just found bizarre I boot Arch Linux KDE, a used RAM value, I use softwares, I close all, a above used RAM value.

seth wrote:

You'll have to look at the meminfo, free defining "used" is way too abstract to make any call here.

Next to the GTT, KDE (by virtue of actually using stuff) could have increased the data in permanent services or some device driver.

bivan · Today 07:50:52

Mesure, with a multimeter? No...

free -h provides "used", while cat /proc/meminfo provides MemTotal & MemFree , so make a substraction: MemTotal - MemFree .

System Monitor, at start then after closing it's Background Services that increased, System Monitor > Applications > Background Services > Details (Show Details Sidebar enabled) precisely there are plasmashell, xdg-desktop-portal-kde, Xwayland, kwin_wayland etc that increased, so yes the culprit is KDE!

So should I complain to https://discuss.kde.org/ ? I hope in the future Arch Linux + KDE make 1, so 1 forum, not 2...

Last edited by bivan (Today 10:03:40)

seth · Today 09:53:54

while cat /proc/meminfo provides MemTotal & MemFree , so make a substraction: MemTotal - MemFree .

meminfo provides *much* more details - if you want to know *why*, that's where you'll have to look.

are plasmashell, xdg-desktop-portal_kde, Xwayland, kwin_wayland etc that increased

That's *while* plasma is running, isn't?

bivan · Today 10:08:58

Yes, they existed at OS start.

Last edited by bivan (Today 10:14:41)

seth · Today 10:15:25

Ah, "Arch Linux KDE" is not a thing and i interpreted

just found bizarre I boot Arch Linux KDE, a used RAM value, I use softwares, I close all, a above used RAM value.

as you starting KDE using software, closing all (incl. KDE)

You still need to compare meminfo in order to see where that "used" memory has gone.

Edit: and the list of processes, eg. sth. like xdg-desktop-portal gets dbus triggered.

Last edited by seth (Today 10:17:14)

bivan · Today 10:38:50

Summary:

I start Arch Linux KDE, System Monitor, RAM used: 1.4 GiB, System Monitor > Applications > Background Services > Details: plasmashell, xdg-desktop-portal-kde, Xwayland, kwin_wayland etc have some memory values (plasmashell: 242.4 MiB),
I start softwares (Dolphin, Chromium...),
I close all the softwares, empty OS, like I just started it,
RAM used: 2.0 GiB, why not 1.4 GiB as before? What is the remaining 0.6 GiB?

echo 3 | sudo tee /proc/sys/vm/drop_caches

RAM used: 1.7 GiB,
plasmashell, xdg-desktop-portal-kde, Xwayland, kwin_wayland etc have its memory values increased (plasmashell: 308.8 MiB).

So 2 culprits: the page cache & KDE (plasmashell, xdg-desktop-portal-kde, Xwayland, kwin_wayland etc).

Page cache ok but I wonder why KDE?

seth · Today 10:54:58

https://en.wikipedia.org/wiki/Memory_management#HEAP eg. plasmashell has probably loaded a bunch of icons and keeps the image (not the compressed file) in some lookup cache.
There's really nothing to phone home about running processes lazily allocating (and releasing, if ever - though ideally the in-process caches are size controlled) memory.

cryptearth · Today 14:00:07

Dolphin

lazy loaded shared objects
when you start dolphin the first time it loads quite a lot in the background - and after closing dolphin this stuff stays loaded because kde expects you to reuse it again (soon) - but instead of dolphin itself it could be a filechooser for up-/download in chromium: why to force unload stuff that very likely will be reused again in the current session?
it's called caching - and it's the very same reason why your browser downloads and saves stuff like page layouts and images as for the same reason each cpu core has its dedicated cache: because going back to primary storage is costly
and although it might sound weird today with flash memory and connections capable of random access several gigabytes per second - when you do that roundtrip enough times it sums up quick and big
it's a design quite old - maybe older than yourself - from a time when storage transfer speed was meassured in kilobytes/second
also: because today memory and storage just became so cheap (in comparison - a 4MB flash card was 1.000DM in the early 90s - today we talk in TB/€ - 4tb is about 200€) so it just doesn matter if a few 100mb are kept in cache
just take it as given - unless you work with microcontrollers such optimization often gets you the exact opposite: higher latency because you keep reloading everything everytime - that will make your system become sliw and sluggish

as seth already mentioned: those caches are in plce for good rwasons - and you usually don't want to purge them

Arch Linux

#1 Yesterday 15:12:40

Why Arch Linux KDE still uses RAM after closing?

#2 Yesterday 15:29:14

Re: Why Arch Linux KDE still uses RAM after closing?

#3 Yesterday 15:59:43

Re: Why Arch Linux KDE still uses RAM after closing?

#4 Yesterday 16:16:27

Re: Why Arch Linux KDE still uses RAM after closing?

#5 Yesterday 18:25:50

Re: Why Arch Linux KDE still uses RAM after closing?

#6 Yesterday 20:18:22

Re: Why Arch Linux KDE still uses RAM after closing?

#7 Yesterday 20:26:51

Re: Why Arch Linux KDE still uses RAM after closing?

#8 Yesterday 20:47:06

Re: Why Arch Linux KDE still uses RAM after closing?

#9 Yesterday 20:51:33

Re: Why Arch Linux KDE still uses RAM after closing?

#10 Yesterday 21:12:44

Re: Why Arch Linux KDE still uses RAM after closing?

#11 Yesterday 21:41:00

Re: Why Arch Linux KDE still uses RAM after closing?

#12 Yesterday 22:50:11

Re: Why Arch Linux KDE still uses RAM after closing?

#13 Today 05:10:54

Re: Why Arch Linux KDE still uses RAM after closing?

#14 Today 07:50:52

Re: Why Arch Linux KDE still uses RAM after closing?

#15 Today 09:53:54

Re: Why Arch Linux KDE still uses RAM after closing?

#16 Today 10:08:58

Re: Why Arch Linux KDE still uses RAM after closing?

#17 Today 10:15:25

Re: Why Arch Linux KDE still uses RAM after closing?

#18 Today 10:38:50

Re: Why Arch Linux KDE still uses RAM after closing?

#19 Today 10:54:58

Re: Why Arch Linux KDE still uses RAM after closing?

#20 Today 14:00:07

Re: Why Arch Linux KDE still uses RAM after closing?

Board footer