Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sounds like lot of issues stem from the transparent aspect of huge pages; that all (un-)mappings are not rounded to huge page size and 4k pages are still supported. Has there been any consideration towards non-transparent huge pages where all that magic does happen and all you got are huge pages?


macOS on Apple Silicon and iOS use 16kiB pages without lying to applications.

Linux has a MAP_HUGETLB constant, which you can pass to mmap(), which opts your application into 2MiB or 1GiB pages. Unfortunately, last time I tried it it required the system admin to enable support in the system for that, which wasn't on by default (on Debian at least). So from the perspective of an ordinary application developer that's useless.


Same on Windows, your memory allocator can request 2MiB or 1GiB pages, and some allocators support this (mimalloc comes to mind), but the admin needs to change a group policy setting to allow that. It's still used by some products like SQL server.


A few years ago at least GB pages were buggy under Windows. I'm not sure of the current siruation.


I do not believe that transparent huge pages works with 1GiB page size under any circumstances. Linux just flat out doesn't support that. The 1G TLBs on x86 are a completely separate hardware facility.


The default in current Debian is on:

  $ cat /sys/kernel/mm/transparent_hugepage/enabled 
  [always] madvise never
  $ grep HUGEPAGE /boot/config-5.10.0-20-amd64 
  CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
  CONFIG_TRANSPARENT_HUGEPAGE=y
  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set


> Unfortunately, last time I tried it it required the system admin to enable support in the system for that

Why??




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: