Debian – Proper way to disable tmpfs on /run/shm

debiantmpfs

How do I disable tmpfs on /run/shm? I searched through initscripts and found that the following code checks the entry in fstab, but what should I change to make it not mount /run/shm? I'm running Debian sid.

/lib/init/mount-functions.sh

read_fstab_entry () {
        # Not found by default.
        found=1

        for file in "$(eval ls $(fstab_files))"; do
                if [ -f "$file" ]; then
                        while read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK; do
                                case "$MNT_FSNAME" in
                                  ""|\#*)
                                        continue;
                                        ;;
                                esac
                                if [ "$MNT_DIR" = "$1" ]; then
                                        if [ -n "$2" ]; then
                                                [ "$MNT_TYPE" = "$2" ] || continue;
                                        fi
                                        found=0
                                        break 2
                                fi
                        done < "$file"
                fi
        done

        return $found

Function callsite

 if read_fstab_entry /run/lock; then
            if [ "$MNT_TYPE" = "tmpfs" ] ; then
                RAMLOCK="yes"
            else
                RAMLOCK="no"
            fi
        fi

Later

if [ yes = "$RAMLOCK" ]; then
                domount "$MNTMODE" tmpfs shmfs /run/lock tmpfs "-o${NODEV}noexec,nosuid$LOCK_OPT"
                # Make sure we don't get cleaned
                touch /run/lock/.tmpfs
        else
                chmod "$LOCK_MODE" /run/lock
        fi

Best Answer

It's not clear what you're trying to achieve. By default (at least on Debian wheezy), /run/shm is a subdirectory of /run, which is mounted as tmpfs. So if you don't want /run/shm to be a mount point, don't change the default configuration. If you create an entry for /run/shm in /etc/fstab, it will be mounted only if you specify the filesystem type; otherwise /dev/shm is bind-mounted there. Not having /run/shm as tmpfs is not a supported configuration. If you want to use some other filesystem type, create an fstab entry and edit /etc/init.d/mountall.sh and /etc/init.d/mountdevsubfs.sh so that they call mount_shm with an argument other than mount or mount_update. Whatever you do, make sure that /run/shm is mode 1777 and has no files left over from a previous boot.

Related Solutions

Use `/run/shm` (formerly `/dev/shm`) as a temp directory

It's perfectly okay to use some directory in /run as long as you have the appropriate rights on it. In some modern distros, /tmp is already a virtual file system in memory or a symlink to a directory inside /run. If this is your case (you can check that in /etc/fstab, or typing mtab), you could use /tmp as your temporary directory.

Also, don't get confused with the article from Debian. shm_* functions are used to create shared memory segments for Inter-Process Communication. With those functions, you can share a fragment of memory between two or more processes to have them communicate or collaborate using the same data. The processes have the segment of memory attached in their own address space and can read and write there as usual. The kernel deals with the complexity. Those functions are not available as shell functions (and wouldn't be very useful in a shell context). For further information, have a look at man 7 shm_overview. The point of the article is that no program should manage directly the pseudo-files representing shared segments, but instead use the appropriate functions to create, attach and delete shared memory segments.

Linux – Difference Between tmpfs, shm, and Hugepages

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 documentation

Quoting:

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 0

Remember 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: 2MB
HugePages Used: None/Off, as evidenced by the all 0's, but enabled as per the 2Mb above.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 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 1Gb

For 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.