Vendo outro post seu, acho que você está usando o zram. Então essa será minha suposição aqui.
Eu fiz a experiência para instalar o zram e consumir muita memória, e obtive a mesma saída de smem do que você. smem não leva em conta zram em sua contagem , usa somente /proc/meminfo para calcular seu valor e, se você procurar e tentar entender o código, verá que o zram RAM ocupa é, no final, contada na coluna noncache da linha kernel dynamic memory .
Investigações adicionais
Seguindo meu pressentimento de que o zram estava por trás desse comportamento, configurei uma VM com especificações semelhantes à sua máquina: 4 GB de RAM e 2 GB de zram swap, sem arquivo de troca.
Carreguei a VM com aplicativos pesados e recebi o seguinte estado:
huygens@ubuntu:~$ smem -wt -K ~/vmlinuz-3.2.0-38-generic.unpacked -R 4096M
Area Used Cache Noncache
firmware/hardware 130717 0 130717
kernel image 13951 0 13951
kernel dynamic memory 1063520 922172 141348
userspace memory 2534684 257136 2277548
free memory 451432 451432 0
----------------------------------------------------------
4194304 1630740 2563564
huygens@ubuntu:~$ free -m
total used free shared buffers cached
Mem: 3954 3528 426 0 79 858
-/+ buffers/cache: 2589 1365
Swap: 1977 0 1977
Como você pode ver, free relata 858 MB de memória cache e é também o que smem parece reportar dentro da memória dinâmica do kernel em cache.
Depois destaquei ainda mais o sistema usando o Chromium Browser. No começo, era apenas 83 MB de swap usado. Mas depois de mais algumas abas abertas, o interruptor de troca rapidamente para quase o máximo e eu experimentei OOM! O zram tem um lado realmente perigoso, quando configurado erroneamente (tamanhos muito grandes), pode rapidamente atingir você como um mecanismo semelhante a um trebuchet.
Naquela época, eu tinha as seguintes saídas:
huygens@ubuntu:~$ smem -wt -K ~/vmlinuz-3.2.0-38-generic.unpacked -R 4096M
Area Used Cache Noncache
firmware/hardware 130717 0 130717
kernel image 13951 0 13951
kernel dynamic memory 1355344 124072 1231272
userspace memory 961004 36456 924548
free memory 1733288 1733288 0
----------------------------------------------------------
4194304 1893816 2300488
huygens@ubuntu:~$ free -m
total used free shared buffers cached
Mem: 3954 2256 1698 0 4 132
-/+ buffers/cache: 2118 1835
Swap: 1977 1750 227
Veja como a memória dinâmica do kernel (cache de colunas e não cache) se parece com o invertido? É porque, no primeiro caso, o kernel tinha memória "cache", como relatado por free , mas tinha memória swap mantida por zram , que smem não sabe como calcular (verifique o código-fonte smem, zram ocupação não é relatada em / proc / meminfo, isso não é computado por smem que faz simples "mem kernel total" - "tipo de memória reportada por meminfo que eu sei que são cache", o que não sabe é que em o mem total do kernel calculado adicionou o tamanho da troca que está na RAM!)
Quando eu estava nesse estado, ativei uma troca de disco rígido e desliguei o zram swap e reinicializei os dispositivos zram: echo 1 > /sys/block/zram0/reset .
Depois disso, a memória do kernel noncache derreteu como a neve no verão e retornou ao valor "normal".
Conclusão
smem não sabe sobre zram (ainda) talvez porque ainda é temporário e, portanto, não faz parte de /proc/meminfo que relata parâmetros globais (como tamanho de páginas ativas, memória total) e depois reportar apenas alguns parâmetros específicos. smem identificou alguns desses parâmetros específicos como "cache", some-os e compare isso com a memória total. Por causa disso, zram de memória usada é contada na coluna noncache .
Nota: a propósito, no kernel moderno, meminfo relata também a memória compartilhada consumida. smem ainda não leva isso em conta, então, mesmo sem zram , a saída de smem deve considerar cuidadosamente esp. se você usa um aplicativo que faz grande uso da memória compartilhada.
Referências utilizadas: