3

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 ~]$
Improve this question

1 Answer 1

Reset to default
4

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

Improve this answer
2
  • Did you mean "Note that SHM_LOCK is not sufficient to page in the locked pages if they're swapped out" ? Commented 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. Commented May 28, 2020 at 12:39

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.