Como Bratchley já indicou, htop, como todo mundo, parece olhar para a linha + em cache de graça. Se você estiver usando um kernel mais antigo que 3.14, então, de fato, isso não muda. Mesmo se você tiver um kernel mais recente, o free e o htop devem ser inteligentes o suficiente para saber onde procurar, mas para obter o valor correto.
Para se aprofundar um pouco no que está acontecendo, confira / proc / meminfo e compare-o para liberar no meu sistema antigo:
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
O tmpfs é contado em shmem, mas também é adicionado à parte "em cache". No Linux antigo (kernel + procps), isso era usado para determinar a memória "Livre", mas isso era bastante problemático, já que a maioria de nós vê a memória em cache como imediatamente recuperável. Este não é mais o caso com tmpfs.
Em um sistema recente (kernel > = 3.14) você encontrará algo novo em / proc / meminfo:
MemAvailable: xxxx kB
Isso leva em conta todos esses elementos e, desde que htop e free dependam desse valor, você obterá uma representação precisa. Note que no meu sistema Debian 8, mesmo que o kernel saiba MemAvailable, este não é o caso:
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**
Uma nota final final:
Na verdade, o tmpfs pode ser bem perigoso. Ao contrário de outros tipos de uso de memória, os arquivos tmpfs não podem ser limpos por um invasor OOM, nem há registro de qual processo realmente criou os arquivos tmpfs. Daí por que o debian 8, por exemplo, escolhe não usar tmpfs para / tmp (ao qual qualquer processo poderia gravar).