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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
