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

Background links on "Unevictable" memory:


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 Answer 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:


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.".

  • Did you mean "Note that SHM_LOCK is not sufficient to page in the locked pages if they're swapped out" ?
    – Juergen
    May 28, 2020 at 10:04
  • @Juergen I do not, but your thinking is correct. It's a quote from a kernel document. The document describes what the kernel is required to do. The kernel is not required to page in the locked pages if they're swapped out.
    – sourcejedi
    May 28, 2020 at 12:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .