Hi all, Does anyone here know if there's a reason transparent hugepages are disabled by default for shmem, as opposed to 'advise' used for anonymous memory? I can't seem to find any mention of why this is the case. Some searching yields e.g. Documentation/admin-guide/mm/transhuge.rst: The default policy is never. mm/shmem.c: static int shmem_huge __read_mostly = SHMEM_HUGE_NEVER; Neither of these have comments as to why. For some background, I'm writing a program that tries to start up and display a (potentially fullscreen) window as quickly as possible. The program only runs on Wayland, and uses software rendering as initialising OpenGL is relatively slow (on the order of 50 ms). This means I need a shared memory buffer to pass to the Wayland compositor. The relevant code looks something like: int fd = memfd_create("wl_shm", 0); ftruncate(fd, buffer_size); uint8_t *data = mmap( NULL, buffer_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); madvise(data, buffer_size, MADV_HUGEPAGE); /* Draw to the buffer. */ For a 2560x1440 screen buffer (~14 MiB) on my desktop, faulting in the pages for this buffer when drawing currently takes ~4-9 ms, which accounts for roughly half the time taken to start up. Enabling transparent hugepages for shmem with echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled drops this time to under 2 ms. On slower computers or for higher resolution screens, the difference is more noticeable. Unfortunately, I can't expect users to tweak this themselves, as it's just a hobby project for general use. For the same reason, I can't use hugetlbfs, as that also requires setup on the part of the user. MADV_COLLAPSE looked promising, but that requires faulting in all the pages first before converting them to hugepages, which is exactly what I'm trying to avoid. Any information is much appreciated. I expect there's a good reason for this default, but it'd be nice to know what it is! Thanks, Phil