Messages in this thread | | | Date | Wed, 4 Aug 2021 17:03:41 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH 07/16] memfd: memfd_create(name, MFD_HUGEPAGE) for shmem huge pages |
| |
On Fri, Jul 30, 2021 at 12:45:49AM -0700, Hugh Dickins wrote: > Commit 749df87bd7be ("mm/shmem: add hugetlbfs support to memfd_create()") > in 4.14 added the MFD_HUGETLB flag to memfd_create(), to use hugetlbfs > pages instead of tmpfs pages: now add the MFD_HUGEPAGE flag, to use tmpfs > Transparent Huge Pages when they can be allocated (flag named to follow > the precedent of madvise's MADV_HUGEPAGE for THPs).
I don't like the interface. THP supposed to be transparent, not yet another hugetlbs.
> /sys/kernel/mm/transparent_hugepage/shmem_enabled "always" or "force" > already made this possible: but that is much too blunt an instrument, > affecting all the very different kinds of files on the internal shmem > mount, and was intended just for ease of testing hugepage loads.
I wounder if your tried "always" in production? What breaks? Maybe we can make it work with a heuristic? This would speed up adoption.
If a tunable needed, I would rather go with fadvise(). It would operate on a couple of bits per struct file and they get translated into VM_HUGEPAGE and VM_NOHUGEPAGE on mmap().
Later if needed fadvise() implementation may be extended to track requested ranges. But initially it can be simple.
-- Kirill A. Shutemov
| |