Linux – Does a tmpfs (/dev/shm) use Linux Page Cache? If it does, then how

cachelinuxlinux-kerneltmpfs

AFAIK, Linux has a page cache to improve performance (example, if you open a file, linux caches that file in RAM), then if file is requested again and it's cached, the OS avoids read the file from disk and returns the file from cache…

My question is: if you have a file in tmpfs and you interact with that file (read), does the file becomes duplicated in RAM (one in the tmpfs and one in the page cache?)

Best Answer

Does a tmpfs use Linux Page Cache?

tmpfs and the page cache are two sides of the same coin.

As described in https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt (emphasis mine)

tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap unneeded pages out to swap space.

[...]

Since tmpfs lives completely in the page cache and on swap, all tmpfs pages will be shown as "Shmem" in /proc/meminfo and "Shared" in free(1).

So as such it would be very unexpected for this cache to be duplicated. It's already in the cache, tmpfs is just a front-end of sorts to the cache system.

My question is: if you have a file in tmpfs and you interact with that file (read), does the file becomes duplicated in RAM (one in the tmpfs and one in the page cache?)

This can be determined experimentally.

# sync
# echo 3 > /proc/sys/vm/drop_caches
# free -m
              total        used        free      shared  buff/cache   available
Mem:          15940        2005       13331         264         603       13390
Swap:             0           0           0

So, I happen to have roughly ~13000 available memory, and no process running that would change it too drastically, and no swap. Let's burn ~6000 on a tmpfs:

# mount -t tmpfs -o size=6000M none /mnt/tmp
# dd if=/dev/urandom of=/mnt/tmp/big.file
dd: writing to '/mnt/tmp/big.file': No space left on device
6291456000 bytes (6.3 GB, 5.9 GiB) copied

So tmpfs filled with random data. What's free now?

# free -m
              total        used        free      shared  buff/cache   available
Mem:          15940        1958        7347        6269        6633        7429
Swap:             0           0           0

So free went down from 13331 to 7347, while shared and buff/cache both went up by 6000. That's interesting, but it still only counts as one, guess that's why they call it shared -.-'

Deliberately reading the file:

# cat /mnt/tmp/big.file > /dev/null
# free -m
              total        used        free      shared  buff/cache   available
Mem:          15940        2055        7237        6269        6647        7332
Swap:             0           0           0

Counts did not go up (not by the order of 6000 anyway).

Deliberatly reading something else:

# cat /some/other/file > /dev/null
# free -m
              total        used        free      shared  buff/cache   available
Mem:          15940        2011         157        6303       13771        7334
Swap:             0           0           0

...and now free is down to 157, cache pretty much full.

So, to summarize: tmpfs itself already represents the page cache. When reading files in tmpfs, they are not duplicated by the page cache anymore.

Related Question