I've been curious lately about the various Linux kernel memory based filesystems. Note: As far as I'm concerned, the questions below should be considered more or less optional when compared with a better understanding of that posed in the title. I ask them below because I believe answering them can better help me to understand the differences, but as my understanding is admittedly limited, it follows that others may know better. I am prepared to accept any answer that enriches my understanding of the differences between the three filesystems mentioned in the title.Ultimately I think I'd like to mount a usable filesystem with hugepages, though some light research (and still lighter tinkering) has led me to believe that a rewritable hugepage mount is not an option. Am I mistaken? What are the mechanics at play here?Also regarding hugepages:     uname -a3.13.3-1-MANJARO \#1 SMP PREEMPT \x86_64 GNU/Linux    tail -n8 /proc/meminfoHugePages_Total:       0HugePages_Free:        0HugePages_Rsvd:        0HugePages_Surp:        0Hugepagesize:       2048 kBDirectMap4k:     8223772 kBDirectMap2M:    16924672 kBDirectMap1G:     2097152 kB(Here are full-text versions of /proc/meminfo and /proc/cpuinfo ) What's going on in the above? Am I already allocating hugepages? Is there a difference between DirectMap memory pages and hugepages?Update After a bit of a nudge from @Gilles, I've added 4 more lines above and it seems there must be a difference, though I'd never heard of DirectMap before pulling that tail yesterday... maybe DMI or something?  Only a little more...Failing any success with the hugepages endeavor, and assuming harddisk backups of any image files, what are the risks of mounting loops from tmpfs? Is my filesystem being swapped the worst-case scenario? I understand tmpfs is mounted filesystem cache - can my mounted loopfile be pressured out of memory? Are there mitigating actions I can take to avoid this?Last - exactly what is shm, anyway? How does it differ from or include either hugepages or tmpfs? 
On system memory... specifically the difference between `tmpfs,` `shm,` and `hugepages...`
linux;filesystems;memory;tmpfs;shared memory
There is no difference betweem tmpfs and shm.  tmpfs is the new name for shm.  shm stands for SHaredMemory.See: Linux tmpfs.The main reason tmpfs is even used today is this comment in my /etc/fstab on my gentoo box.  BTW Chromium won't build with the line missing:# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0 which came out of the linux kernel documentationQuoting:tmpfs has the following uses:1) There is always a kernel internal mount which you will not see at  all. This is used for shared anonymous mappings and SYSV shared  memory. This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not   set, the user visible part of tmpfs is not build. But the internal  mechanisms are always present.2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for  POSIX shared memory (shm_open, shm_unlink). Adding the following  line to /etc/fstab should take care of this:tmpfs   /dev/shm    tmpfs   defaults    0 0Remember to create the directory that you intend to mount tmpfs on   if necessary.This mount is not needed for SYSV shared memory. The internal  mount is used for that. (In the 2.3 kernel versions it was  necessary to mount the predecessor of tmpfs (shm fs) to use SYSV  shared memory)3) Some people (including me) find it very convenient to mount it  e.g. on /tmp and /var/tmp and have a big swap partition. And now  loop mounts of tmpfs files do work, so mkinitrd shipped by most  distributions should succeed with a tmpfs /tmp.4) And probably a lot more I do not know about :-)tmpfs has three mount options for sizing:  size:      The limit of allocated bytes for this tmpfs instance. The              default is half of your physical RAM without swap. If you             oversize your tmpfs instances the machine will deadlock             since the OOM handler will not be able to free that memory.nr_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE.nr_inodes: The maximum number of inodes for this instance. The default             is half of the number of your physical RAM pages, or (on a             machine with highmem) the number of lowmem RAM pages,             whichever is the lower.From the Transparent Hugepage Kernel Doc:Transparent Hugepage Support maximizes the usefulness of free memory  if compared to the reservation approach of hugetlbfs by allowing all  unused memory to be used as cache or other movable (or even unmovable  entities). It doesn't require reservation to prevent hugepage  allocation failures to be noticeable from userland. It allows paging  and all other advanced VM features to be available on the hugepages.  It requires no modifications for applications to take advantage of it.Applications however can be further optimized to take advantage of  this feature, like for example they've been optimized before to avoid  a flood of mmap system calls for every malloc(4k). Optimizing userland  is by far not mandatory and khugepaged already can take care of long  lived page allocations even for hugepage unaware applications that  deals with large amounts of memory.New Comment after doing some calculations:HugePage Size: 2MBHugePages Used: None/Off, as evidenced by the all 0's, but enabled as per the 2Mb above.DirectMap4k: 8.03GbDirectMap2M: 16.5GbDirectMap1G: 2Gb  Using the Paragraph above regarding Optimization in THS, it looks as tho 8Gb of your memory is being used by applications that operate using mallocs of 4k, 16.5Gb, has been requested by applications using mallocs of 2M.  The applications using mallocs of 2M are mimicking HugePage Support by offloading the 2M sections to the kernel.  This is the preferred method, because once the malloc is released by the kernel, the memory is released to the system, whereas mounting tmpfs using hugepage wouldn't result in a full cleaning until the system was rebooted.  Lastly, the easy one, you had 2 programs open/running that requested a malloc of 1GbFor those of you reading that don't know a malloc is a Standard Structure in C that stands for Memory ALLOCation.  These calculations serve as proof that the OP's correlation between DirectMapping and THS maybe correct.  Also note that mounting a HUGEPAGE ONLY fs would only result in a gain in Increments of 2MB, whereas letting the system manage memory using THS occurs mostly in 4k blocks, meaning in terms of memory management every malloc call saves the system 2044k(2048 - 4) for some other process to use.