The tmpfs would only use that 43MB if you filled it. It does not reserve the memory in advance. However:
Believe it or not, the 39M "shared" figure cannot be dropped, and it is all counted as "buff/cache". It includes all your tmpfs files. It also includes "shared" memory which is allocated from a secret kernel tmpfs :-). This includes "system V shared memory", and also some types of graphics buffers.
Anyway, those two mistakes roughly cancel out. So what about the rest of the memory?
When you drop caches in Linux, it chooses not to drop any cache which is mapped by a currently running program. Many of these mappings will be program/library code files.
Some data files may also be mapped. For example when you run
journalctl to browse the
systemd log, it accesses the log files using
mmap() (as opposed to
You can check what the remaining caches are with
sudo smem -t -m. I expect they will mostly be currently running programs, and the libraries they use.
In case you want to verify this, here are links to the kernel code:
drop_caches works by calling invalidate_mapping_pages() for each cached "inode" (file).
invalidate_mapping_pages() - Invalidate all the unlocked pages of one inode
invalidate_mapping_pages() will not block on IO activity. It will not
invalidate pages which are dirty, locked, under writeback or mapped into
If you had any "dirty" pages - cached writes - or in-progress writes, those would also not be dropped or waited for. This was also mentioned in Documentation/sysctl/vm.txt.
In the case of a dirty/writeback page, invalidate_mapping_pages() "[tries] to speed up its reclaim" by calling deactivate_file_page(). I did not check exactly what this means :-).