Does Linux kernel 5.0.9 have a memory leak?

Question

likely similar to Linux memory usage higher than sum of processes except that I have observed used memory going both below and above the sum of process RSS by GBs.

uname -sr

Linux 5.0.9-...

cat /proc/meminfo

MemTotal:        8155920 kB
MemFree:          280200 kB
MemAvailable:     328152 kB
Buffers:             144 kB
Cached:           704380 kB
SwapCached:        15440 kB
Active:          2374160 kB
Inactive:        1195784 kB
Active(anon):    2259104 kB
Inactive(anon):  1026600 kB
Active(file):     115056 kB
Inactive(file):   169184 kB
Unevictable:      238012 kB
Mlocked:               0 kB
SwapTotal:       8388604 kB
SwapFree:        5908220 kB
Dirty:               168 kB
Writeback:             0 kB
AnonPages:       3097284 kB
Mapped:           255492 kB
Shmem:            420252 kB
KReclaimable:      81636 kB
Slab:             346972 kB
SReclaimable:      81636 kB
SUnreclaim:       265336 kB
KernelStack:       14720 kB
PageTables:        70776 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12466564 kB
Committed_AS:    9429628 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
Percpu:             2112 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:     4764008 kB
DirectMap2M:     3614720 kB

the sum of RSS by all processes (summed individually from top output), slabinfo, buff/cache, swap don't change by more than 100 MBs and yet available memory will increase by GBs after starting ffmpeg... starting ffmpeg on a heavy long term compression task seems to reliably eliminate all disk thrashing and dramatically increase available memory every time (good temp solution, but not acceptable as a long term solution). As ffmpeg runs available memory will drop and the disk will thrash but available memory will then increase by GBs, this behavior remains only so long as ffmpeg is running. If ffmpeg is not running then available memory will go from causing disk thrashing to a few hundred MBs at most. No other program seems to have the same effect for the last ~two months or so of system use. Amusing and annoying.

Answer 1

Mind you I'm coming from mainly BSD based systems. But as I see your situation it looks very similar. Your data looks to me to be working "as intended". Memory is preferred over swap because it's infinitely faster. So your system is doing it's best to manage that memory, and only allow applications to use it it, as the system sees fit -- not the application. IOW your system consumes the memory so it can broker that resource as it sees fit. Not the other way round.

Now I might add. That if you don't approve of that. You do have the option of "tuning" your kernel to change it's behavior to your own liking. But honestly; it looks good to me.

HTH

Answer 2

Committed_AS is greater than MemTotal so you will eventually page out. When a threshold is reached, memory reclaim will drop some caches, page out some to disk, and similar activity.

If you don't like this reclaim behavior, add more RAM.

A "memory leak" in a program or the kernel that actually loses track of allocated memory is a serious claim. Please do not confuse reclaim behavior with leaks of the kind found with tools like Valgrind or LeakSanitizer.