Ebbe futottam én is bele, de Arch-on. Sokáig azt hittem, hogy ez egy 6.4 kerneles bug, közben meg az API változott. Nem csak a free parancsot, de a top, vmstat-ot is érinti. Ezzel zavarban vagyok. Most ez a valós fogyasztás, és régen voltunk átverve, hogy optimistán kevesebbet mutatott, vagy fordítva, régen mutatta a tényleges használt memóriát, és most vagyunk ezzel a megemelkedett értékkel pesszimistán becsapva?
Az is igaz, hogy ez a memóriafogyasztás iszonyat nehezen mérhető, már eleve az is, hogy egy alkalmazás mennyit fogyaszt, meg hogy az egész rendszer. Ennek a kijelzése egyébként más rendszeren is megbízhatatlan, pl. OpenBSD-n szinte ugyanaz a bspwm + polybar + st rendszer 89 MB memóriát evett, ami Arch-on akkor 200 fölött (bár Archon ott a systemd, pulseaudio volt még akkor, meg a Linux kernel, GPU driver is komplexebb, máshogy számolja a fogyasztott memóriát is). OpenBSD-n is épp úgy vmstat-tal és top-pal mérve (BSD-ken nincs free parancs, bár Vermaden csinált hozzá, nem használtam még), azonos gépen, hardveren nézve természetesen.
Már egy alkalmazásnál is vita van, hogy az rss (resident set size) = uss (unique set size, amit a program binárisa eszik egymagában) + shared (használt shared libek) értékét, meg a virtuális memóriát hogy kell figyelembe venni, meg van, aki pss (proportional set size) értéket használ, az a shared értékét szétosztja az összes futó bináris között, ami ugyanazokat a libeket használja, olyan indoklással esküdnek a pss-re, hogy az uss túl alacsony, az rss meg túl nagy, egyik sem valós érték. Linux kernel is a /proc/meminfo alatt figyelembe vesz mindenféle töredezést, pagetables veszteséget, de még slab-et is számol, meg van active, inactive memóriával is keverés (az BSD-ken is van), kész káosz, hogy akkor most melyik mi, az egész cucc tényleg mennyit eszik.
Ha nagyon igazságosak akarunk lenni, akkor a modern Windows sem pontosan jelzi ki a memóriát. Belemér mindenféle cache-t, meg memóriatöredezettséget, meg egyes folyamatok túljelentik, hogy mekkora memóriára van szükségük, így lényegében egyik rendszeren sem tudni, hogy PONTOSAN mi mennyi memóriát eszik, mennyivel éri be, mert még aszerint is változik, hogy mennyi RAM van a gépben, ha pl. 8 gigával nézzük, akkor kisebb memóriafogyasztást ír, mint ugyanazon gépen, rendszer alól 16 gigával, mivel több előre foglalást, igénybejelentést, nagyobb cache-t enged. Ez utoljára talán max. DOS alatt volt világos, hogy mi mennyi memóriát eszik.
Az is igaz, hogy nekünk sem kéne a free parancs used oszlopát fetisizálni, de ugye valamin mérni kell a az egyes szoftveres megoldások, alkalmazások, WM-ek, OS-ek foglalását, hogy össze lehessen hasonlítani, hogy melyik mennyire bloat a másikhoz képest. Ezért én sima processeknél az rss-t veszem figyelembe, kernelnél meg a slab-et. Nyilván a saját rendszeremen, mivel nálam nincs se swap, se zswap, se más extra trükközés (se komplex fájlrendszerek, mint btrfs, ZFS, csak sima ext4 megy, alapbeállításokkal, semmi tömörítés vagy szoftveres titkosítás). A buffers/cache-t sem számolom bele, mert azt bármikor eldobja a rendszer, ha kell a memória, illetve free shared oszlopát sem, mert azt meg a tmpfs-ek foglalják főként, és nem az alkalmazások mérőfoka.
Mindenesetre, ami engem illet, írok magamnak saját free implementációt, ami /proc/meminfo-ból a régi módszerrel számolja, used = total - ( free + shared + buff/cache ) alapon, és nem az új used = total - available módszerrel. Csak a konzekvens számolás miatt, hogy a régi mérésekkel összehasonlítható legyen. Úgyis akartam már ilyet írni, hogy BSD-ken is használni tudjam, ahol csak vmstat/top van.