As Bratchley already indicated, htop, like everybody, seems to look at the +- cached line in free. If you are using a kernel older than 3.14, then indeed, that does not change. Even if you have a more recent kernel, free and htop have to be smart enough to know where to look though to get the right value.
To get a bit deeper into what's happening, check out /proc/meminfo and compare it to free on my old system:
root@localhost:/media/user# free
total used free shared buffers cached
Mem: 291152 268264 22888 0 0 47180
-/+ buffers/cache: 221084 **70068**
Swap: 0 0 0
root@localhost:/media/user# cat /proc/meminfo
MemTotal: 291152 kB
MemFree: **22904** kB
Buffers: 0 kB
Cached: **47144** kB
SwapCached: 0 kB
Active: 154752 kB
Inactive: 32376 kB
Active(anon): 143632 kB
Inactive(anon): 21936 kB
Active(file): 11120 kB
Inactive(file): 10440 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 139996 kB
Mapped: 25276 kB
Shmem: **25584** kB
Slab: 64096 kB
SReclaimable: 3364 kB
SUnreclaim: 60732 kB
KernelStack: 2280 kB
PageTables: 3588 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 145576 kB
Committed_AS: 1500824 kB
VmallocTotal: 499712 kB
VmallocUsed: 7256 kB
VmallocChunk: 449196 kB
The tmpfs is counted under shmem, but is also added into the "cached" portion. In older Linux (kernel + procps), this was used to determine the "Free" memory, but this was pretty problematic, since most of us see cached memory as immediately reclaimable. This is not the case anymore with tmpfs.
On a recent system (kernel >= 3.14) you will find something new under /proc/meminfo:
MemAvailable: xxxx kB
This does take all these elements into account, and as long as htop and free were to rely on this value, you would get an accurate representation. Note that on my Debian 8 system, even though the kernel knows MemAvailable, this is not the case:
ardi@oab1ardi-mcdev:~/mc/oattest1/workspace/bcm_linux_3_4rt$ cat /proc/meminfo | grep Avail
MemAvailable: **1319148** kB
ardi@oab1ardi-mcdev:~/$ free
total used free shared buffers cached
Mem: 2058360 1676332 382028 33116 40356 933916
-/+ buffers/cache: 702060 **1356300**
Swap: 0 0 0
ardi@oab1ardi-mcdev:~/$ sudo dd if=/dev/zero bs=1M count=200 of=/run/delme
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 0.0628098 s, 3.3 GB/s
ardi@oab1ardi-mcdev:~/$ free
total used free shared buffers cached
Mem: 2058360 1881060 177300 237916 40372 1138720
-/+ buffers/cache: 701968 **1356392**
Swap: 0 0 0
ardi@oab1ardi-mcdev:~/mc/oattest1/workspace/bcm_linux_3_4rt$ cat /proc/meminfo | grep Avail
MemAvailable: **1114152 kB**
A final sidenote:
In fact, tmpfs can be pretty dangerous. Unlike other types of memory usage, tmpfs files cannot be cleaned up by an OOM killer, nor is there any record of which process actually created the tmpfs files. Hence why debian 8 for example chooses not to use tmpfs for /tmp (which any process could write to).
Credits to the following links:
https://linuxraj.wordpress.com/2015/03/10/memory-utilization-from-procmeminfo-memavailable/
https://rwmj.wordpress.com/2012/09/12/tmpfs-considered-harmful/
I figured I could just test it, so I ran:
sudo mount -o remount,size=2800M /run
Worked like a charm:
Filesystem Size Used Avail Use% Mounted on
tmpfs 2.8G 45M 2.7G 2% /run
So I filled it a bit:
fallocate -l 1G /run/test.img
fallocate -l 1G /run/test2.img
fallocate -l 500M /run/test3.img
Result:
Filesystem Size Used Avail Use% Mounted on
tmpfs 2.8G 2.6G 208M 93% /run
System is still up and running. Swap availability dropped, which proves it was used:
- 17:10: create 2.5 GB of files in
/run
- 17:20: remove the 500M file
Total swap is reduced by the amount taken by /run
.
I'd test 10GB on a VM, because I don't know if the kernel will refuse the remount or just have an unexpected behavior.
I'm still looking for an actual answer, but the pragmatic way showed it works.
Best Answer
I get the impression you have a few misconceptions regarding
tmpfs
. You might find it useful to read the kernel documentation on the topic; I’ll attempt to clarify things for you here.Your question’s title “
tmpfs
does not overflow to swap” doesn’t seem to reflect the actual contents of your question, but in any casetmpfs
does use swap, although arguably it doesn’t overflow to swap.tmpfs
is fundamentally a (virtual) memory-based file system; its contents live in memory only, but since they’re swappable the kernel can store them in swap instead of physical memory if necessary. Neverthelesstmpfs
file systems can’t be larger than the total amount of virtual memory available, i.e. physical RAM and swap, as indicated e.g. byfree -h
.By default
tmpfs
file systems have a maximum size equal to half the amount of physical memory available. You can increase this using thesize
parameter, but again it can’t ever be more than the available physical memory and swap (although that limit isn’t enforced at mount time). Once the file system reaches its maximum size (or rather, contains files occupying that much space), it reports that it’s run out of space, as you found out.tmpfs
itself doesn’t support overflowing anywhere when it runs out of space.If you need temporary storage space for large files, you should use
/var/tmp
rather than/tmp
. You really don’t want a very largetmpfs
file system, that’s a recipe for disaster when it fills up (the kernel’s usual ways of recovering memory don’t work in atmpfs
).(If you have lots of RAM of course, a large
tmpfs
can work. I run a few systems with buildtmpfs
file systems sized at 75% of RAM, out of 32GiB, 64GiB or even more.)