I read about tmpfs and got curious to get the benefits from it. So, I created a directory and mounted as tmpfs.

So, as per theory, whatever is written in tmpfs gets stored on RAM directly and lasts till reboot. So, I created a 10 GB of file on tmpfs drive. As per theory, htop/top command must show RAM consumption to be more than 10 GB. I have 256 GB of RAM, but my RAM consumption was less and same as it was before creation of 10 GB of file on tmpfs.

Is there something that I missed out?

  • What about the free command?
    – muru
    Dec 28, 2014 at 18:29
  • 2
    Possibly you dropped 10gbs cache when caching the new 10gb file? Also - what's in the 10gb file - \0s? That wouldn't consume any memory - /tmpfs understands file holes.
    – mikeserv
    Dec 28, 2014 at 18:29
  • 1
    @muru - fancy meeting you here...
    – mikeserv
    Dec 28, 2014 at 18:32
  • I just tested the creation of a 4GB file in tmpfs (populated form /dev/zero) and my free memory jumped by 4GB after I deleted it. It seems to have itemized it as cached data so if you're looking at the +/- buffers/cache line it won't change.
    – Bratchley
    Dec 28, 2014 at 18:32
  • 1
    Ah I forgot he was asking about htop specifically. Just checked on my system and it's showing memory used sans cache so that's probably the issue. The htop metric doesn't account for the area it's actually storing the file data in.
    – Bratchley
    Dec 28, 2014 at 18:38

1 Answer 1


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/

You must log in to answer this question.

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