1

Why is "Unevictable" memory larger than “Mlocked” memory?

$ cp /proc/meminfo meminfo
$ grep -iE "lock|evictable" meminfo
Unevictable:      161436 kB
Mlocked:           12772 kB

$ uname -r  # My kernel version
5.0.17-200.fc29.x86_64

Background links on "Unevictable" memory:

https://superuser.com/questions/1135809/odd-behaviour-with-unevictable-cache-linux-kernel/1449088#1449088

The kernel is compiled with standard support for tmpfs. I cannot see any ramfs (i.e. any unswappable ram filesystem).

$ df -t ramfs
df: no file systems processed

$ cat meminfo
MemTotal:        8042664 kB
MemFree:         3733932 kB
MemAvailable:    5175960 kB
Buffers:          193684 kB
Cached:          1810672 kB
SwapCached:        14628 kB
Active:          2020900 kB
Inactive:        1644208 kB
Active(anon):    1127976 kB
Inactive(anon):   945940 kB
Active(file):     892924 kB
Inactive(file):   698268 kB
Unevictable:      161436 kB
Mlocked:           12772 kB
SwapTotal:       2097148 kB
SwapFree:        1465180 kB
Dirty:               312 kB
Writeback:             0 kB
AnonPages:       1813196 kB
Mapped:           539216 kB
Shmem:            408808 kB
KReclaimable:     160752 kB
Slab:             320584 kB
SReclaimable:     160752 kB
SUnreclaim:       159832 kB
KernelStack:       17792 kB
PageTables:        37288 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     6118480 kB
Committed_AS:   11410784 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
Percpu:             3424 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:      492084 kB
DirectMap2M:     7774208 kB
DirectMap1G:     1048576 kB
[alan@alan-laptop ~]$ 
1

One document in the background material mentions mapping_set_unevictable(). It says it was used in two cases:

  1. By ramfs to mark the address spaces of its inodes when they are created, and this mark remains for the life of the inode.

  2. By SYSV SHM to mark SHM_LOCK'd address spaces until SHM_UNLOCK is called.

    Note that SHM_LOCK is not required to page in the locked pages if they're swapped out; the application must touch the pages manually if it wants to ensure they're in memory.

It is now used in a third case. It is applied to i915 graphics buffers, if they are mapped by the GPU:

https://elixir.bootlin.com/linux/v5.0.17/ident/mapping_set_unevictable

Referenced in 4 files:

"The Global Graphics Translation Table (GTT) [...] takes care of the address mapping from the GPU virtual address space to physical addresses.".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.