Documentation/admin-guide/mm/transhuge.rst

   1 .. _admin_guide_transhuge:
   2
   3 ============================
   4 Transparent Hugepage Support
   5 ============================
   6
   7 Objective
   8 =========
   9
  10 Performance critical computing applications dealing with large memory
  11 working sets are already running on top of libhugetlbfs and in turn
  12 hugetlbfs. Transparent HugePage Support (THP) is an alternative mean of
  13 using huge pages for the backing of virtual memory with huge pages
  14 that supports the automatic promotion and demotion of page sizes and
  15 without the shortcomings of hugetlbfs.
  16
  17 Currently THP only works for anonymous memory mappings and tmpfs/shmem.
  18 But in the future it can expand to other filesystems.
  19
  20 .. note::
  21    in the examples below we presume that the basic page size is 4K and
  22    the huge page size is 2M, although the actual numbers may vary
  23    depending on the CPU architecture.
  24
  25 The reason applications are running faster is because of two
  26 factors. The first factor is almost completely irrelevant and it's not
  27 of significant interest because it'll also have the downside of
  28 requiring larger clear-page copy-page in page faults which is a
  29 potentially negative effect. The first factor consists in taking a
  30 single page fault for each 2M virtual region touched by userland (so
  31 reducing the enter/exit kernel frequency by a 512 times factor). This
  32 only matters the first time the memory is accessed for the lifetime of
  33 a memory mapping. The second long lasting and much more important
  34 factor will affect all subsequent accesses to the memory for the whole
  35 runtime of the application. The second factor consist of two
  36 components:
  37
  38 1) the TLB miss will run faster (especially with virtualization using
  39    nested pagetables but almost always also on bare metal without
  40    virtualization)
  41
  42 2) a single TLB entry will be mapping a much larger amount of virtual
  43    memory in turn reducing the number of TLB misses. With
  44    virtualization and nested pagetables the TLB can be mapped of
  45    larger size only if both KVM and the Linux guest are using
  46    hugepages but a significant speedup already happens if only one of
  47    the two is using hugepages just because of the fact the TLB miss is
  48    going to run faster.
  49
  50 THP can be enabled system wide or restricted to certain tasks or even
  51 memory ranges inside task's address space. Unless THP is completely
  52 disabled, there is ``khugepaged`` daemon that scans memory and
  53 collapses sequences of basic pages into huge pages.
  54
  55 The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
  56 interface and using madvise(2) and prctl(2) system calls.
  57
  58 Transparent Hugepage Support maximizes the usefulness of free memory
  59 if compared to the reservation approach of hugetlbfs by allowing all
  60 unused memory to be used as cache or other movable (or even unmovable
  61 entities). It doesn't require reservation to prevent hugepage
  62 allocation failures to be noticeable from userland. It allows paging
  63 and all other advanced VM features to be available on the
  64 hugepages. It requires no modifications for applications to take
  65 advantage of it.
  66
  67 Applications however can be further optimized to take advantage of
  68 this feature, like for example they've been optimized before to avoid
  69 a flood of mmap system calls for every malloc(4k). Optimizing userland
  70 is by far not mandatory and khugepaged already can take care of long
  71 lived page allocations even for hugepage unaware applications that
  72 deals with large amounts of memory.
  73
  74 In certain cases when hugepages are enabled system wide, application
  75 may end up allocating more memory resources. An application may mmap a
  76 large region but only touch 1 byte of it, in that case a 2M page might
  77 be allocated instead of a 4k page for no good. This is why it's
  78 possible to disable hugepages system-wide and to only have them inside
  79 MADV_HUGEPAGE madvise regions.
  80
  81 Embedded systems should enable hugepages only inside madvise regions
  82 to eliminate any risk of wasting any precious byte of memory and to
  83 only run faster.
  84
  85 Applications that gets a lot of benefit from hugepages and that don't
  86 risk to lose memory by using hugepages, should use
  87 madvise(MADV_HUGEPAGE) on their critical mmapped regions.
  88
  89 .. _thp_sysfs:
  90
  91 sysfs
  92 =====
  93
  94 Global THP controls
  95 -------------------
  96
  97 Transparent Hugepage Support for anonymous memory can be entirely disabled
  98 (mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
  99 regions (to avoid the risk of consuming more memory resources) or enabled
 100 system wide. This can be achieved with one of::
 101
 102         echo always >/sys/kernel/mm/transparent_hugepage/enabled
 103         echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
 104         echo never >/sys/kernel/mm/transparent_hugepage/enabled
 105
 106 It's also possible to limit defrag efforts in the VM to generate
 107 anonymous hugepages in case they're not immediately free to madvise
 108 regions or to never try to defrag memory and simply fallback to regular
 109 pages unless hugepages are immediately available. Clearly if we spend CPU
 110 time to defrag memory, we would expect to gain even more by the fact we
 111 use hugepages later instead of regular pages. This isn't always
 112 guaranteed, but it may be more likely in case the allocation is for a
 113 MADV_HUGEPAGE region.
 114
 115 ::
 116
 117         echo always >/sys/kernel/mm/transparent_hugepage/defrag
 118         echo defer >/sys/kernel/mm/transparent_hugepage/defrag
 119         echo defer+madvise >/sys/kernel/mm/transparent_hugepage/defrag
 120         echo madvise >/sys/kernel/mm/transparent_hugepage/defrag
 121         echo never >/sys/kernel/mm/transparent_hugepage/defrag
 122
 123 always
 124         means that an application requesting THP will stall on
 125         allocation failure and directly reclaim pages and compact
 126         memory in an effort to allocate a THP immediately. This may be
 127         desirable for virtual machines that benefit heavily from THP
 128         use and are willing to delay the VM start to utilise them.
 129
 130 defer
 131         means that an application will wake kswapd in the background
 132         to reclaim pages and wake kcompactd to compact memory so that
 133         THP is available in the near future. It's the responsibility
 134         of khugepaged to then install the THP pages later.
 135
 136 defer+madvise
 137         will enter direct reclaim and compaction like ``always``, but
 138         only for regions that have used madvise(MADV_HUGEPAGE); all
 139         other regions will wake kswapd in the background to reclaim
 140         pages and wake kcompactd to compact memory so that THP is
 141         available in the near future.
 142
 143 madvise
 144         will enter direct reclaim like ``always`` but only for regions
 145         that are have used madvise(MADV_HUGEPAGE). This is the default
 146         behaviour.
 147
 148 never
 149         should be self-explanatory.
 150
 151 By default kernel tries to use huge zero page on read page fault to
 152 anonymous mapping. It's possible to disable huge zero page by writing 0
 153 or enable it back by writing 1::
 154
 155         echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 156         echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 157
 158 Some userspace (such as a test program, or an optimized memory allocation
 159 library) may want to know the size (in bytes) of a transparent hugepage::
 160
 161         cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
 162
 163 khugepaged will be automatically started when
 164 transparent_hugepage/enabled is set to "always" or "madvise, and it'll
 165 be automatically shutdown if it's set to "never".
 166
 167 Khugepaged controls
 168 -------------------
 169
 170 khugepaged runs usually at low frequency so while one may not want to
 171 invoke defrag algorithms synchronously during the page faults, it
 172 should be worth invoking defrag at least in khugepaged. However it's
 173 also possible to disable defrag in khugepaged by writing 0 or enable
 174 defrag in khugepaged by writing 1::
 175
 176         echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/defrag
 177         echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/defrag
 178
 179 You can also control how many pages khugepaged should scan at each
 180 pass::
 181
 182         /sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan
 183
 184 and how many milliseconds to wait in khugepaged between each pass (you
 185 can set this to 0 to run khugepaged at 100% utilization of one core)::
 186
 187         /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs
 188
 189 and how many milliseconds to wait in khugepaged if there's an hugepage
 190 allocation failure to throttle the next allocation attempt::
 191
 192         /sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs
 193
 194 The khugepaged progress can be seen in the number of pages collapsed (note
 195 that this counter may not be an exact count of the number of pages
 196 collapsed, since "collapsed" could mean multiple things: (1) A PTE mapping
 197 being replaced by a PMD mapping, or (2) All 4K physical pages replaced by
 198 one 2M hugepage. Each may happen independently, or together, depending on
 199 the type of memory and the failures that occur. As such, this value should
 200 be interpreted roughly as a sign of progress, and counters in /proc/vmstat
 201 consulted for more accurate accounting)::
 202
 203         /sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed
 204
 205 for each pass::
 206
 207         /sys/kernel/mm/transparent_hugepage/khugepaged/full_scans
 208
 209 ``max_ptes_none`` specifies how many extra small pages (that are
 210 not already mapped) can be allocated when collapsing a group
 211 of small pages into one large page::
 212
 213         /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
 214
 215 A higher value leads to use additional memory for programs.
 216 A lower value leads to gain less thp performance. Value of
 217 max_ptes_none can waste cpu time very little, you can
 218 ignore it.
 219
 220 ``max_ptes_swap`` specifies how many pages can be brought in from
 221 swap when collapsing a group of pages into a transparent huge page::
 222
 223         /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap
 224
 225 A higher value can cause excessive swap IO and waste
 226 memory. A lower value can prevent THPs from being
 227 collapsed, resulting fewer pages being collapsed into
 228 THPs, and lower memory access performance.
 229
 230 ``max_ptes_shared`` specifies how many pages can be shared across multiple
 231 processes. Exceeding the number would block the collapse::
 232
 233         /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared
 234
 235 A higher value may increase memory footprint for some workloads.
 236
 237 Boot parameter
 238 ==============
 239
 240 You can change the sysfs boot time defaults of Transparent Hugepage
 241 Support by passing the parameter ``transparent_hugepage=always`` or
 242 ``transparent_hugepage=madvise`` or ``transparent_hugepage=never``
 243 to the kernel command line.
 244
 245 Hugepages in tmpfs/shmem
 246 ========================
 247
 248 You can control hugepage allocation policy in tmpfs with mount option
 249 ``huge=``. It can have following values:
 250
 251 always
 252     Attempt to allocate huge pages every time we need a new page;
 253
 254 never
 255     Do not allocate huge pages;
 256
 257 within_size
 258     Only allocate huge page if it will be fully within i_size.
 259     Also respect fadvise()/madvise() hints;
 260
 261 advise
 262     Only allocate huge pages if requested with fadvise()/madvise();
 263
 264 The default policy is ``never``.
 265
 266 ``mount -o remount,huge= /mountpoint`` works fine after mount: remounting
 267 ``huge=never`` will not attempt to break up huge pages at all, just stop more
 268 from being allocated.
 269
 270 There's also sysfs knob to control hugepage allocation policy for internal
 271 shmem mount: /sys/kernel/mm/transparent_hugepage/shmem_enabled. The mount
 272 is used for SysV SHM, memfds, shared anonymous mmaps (of /dev/zero or
 273 MAP_ANONYMOUS), GPU drivers' DRM objects, Ashmem.
 274
 275 In addition to policies listed above, shmem_enabled allows two further
 276 values:
 277
 278 deny
 279     For use in emergencies, to force the huge option off from
 280     all mounts;
 281 force
 282     Force the huge option on for all - very useful for testing;
 283
 284 Need of application restart
 285 ===========================
 286
 287 The transparent_hugepage/enabled values and tmpfs mount option only affect
 288 future behavior. So to make them effective you need to restart any
 289 application that could have been using hugepages. This also applies to the
 290 regions registered in khugepaged.
 291
 292 Monitoring usage
 293 ================
 294
 295 The number of anonymous transparent huge pages currently used by the
 296 system is available by reading the AnonHugePages field in ``/proc/meminfo``.
 297 To identify what applications are using anonymous transparent huge pages,
 298 it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
 299 for each mapping.
 300
 301 The number of file transparent huge pages mapped to userspace is available
 302 by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
 303 To identify what applications are mapping file transparent huge pages, it
 304 is necessary to read ``/proc/PID/smaps`` and count the FileHugeMapped fields
 305 for each mapping.
 306
 307 Note that reading the smaps file is expensive and reading it
 308 frequently will incur overhead.
 309
 310 There are a number of counters in ``/proc/vmstat`` that may be used to
 311 monitor how successfully the system is providing huge pages for use.
 312
 313 thp_fault_alloc
 314         is incremented every time a huge page is successfully
 315         allocated to handle a page fault.
 316
 317 thp_collapse_alloc
 318         is incremented by khugepaged when it has found
 319         a range of pages to collapse into one huge page and has
 320         successfully allocated a new huge page to store the data.
 321
 322 thp_fault_fallback
 323         is incremented if a page fault fails to allocate
 324         a huge page and instead falls back to using small pages.
 325
 326 thp_fault_fallback_charge
 327         is incremented if a page fault fails to charge a huge page and
 328         instead falls back to using small pages even though the
 329         allocation was successful.
 330
 331 thp_collapse_alloc_failed
 332         is incremented if khugepaged found a range
 333         of pages that should be collapsed into one huge page but failed
 334         the allocation.
 335
 336 thp_file_alloc
 337         is incremented every time a file huge page is successfully
 338         allocated.
 339
 340 thp_file_fallback
 341         is incremented if a file huge page is attempted to be allocated
 342         but fails and instead falls back to using small pages.
 343
 344 thp_file_fallback_charge
 345         is incremented if a file huge page cannot be charged and instead
 346         falls back to using small pages even though the allocation was
 347         successful.
 348
 349 thp_file_mapped
 350         is incremented every time a file huge page is mapped into
 351         user address space.
 352
 353 thp_split_page
 354         is incremented every time a huge page is split into base
 355         pages. This can happen for a variety of reasons but a common
 356         reason is that a huge page is old and is being reclaimed.
 357         This action implies splitting all PMD the page mapped with.
 358
 359 thp_split_page_failed
 360         is incremented if kernel fails to split huge
 361         page. This can happen if the page was pinned by somebody.
 362
 363 thp_deferred_split_page
 364         is incremented when a huge page is put onto split
 365         queue. This happens when a huge page is partially unmapped and
 366         splitting it would free up some memory. Pages on split queue are
 367         going to be split under memory pressure.
 368
 369 thp_split_pmd
 370         is incremented every time a PMD split into table of PTEs.
 371         This can happen, for instance, when application calls mprotect() or
 372         munmap() on part of huge page. It doesn't split huge page, only
 373         page table entry.
 374
 375 thp_zero_page_alloc
 376         is incremented every time a huge zero page used for thp is
 377         successfully allocated. Note, it doesn't count every map of
 378         the huge zero page, only its allocation.
 379
 380 thp_zero_page_alloc_failed
 381         is incremented if kernel fails to allocate
 382         huge zero page and falls back to using small pages.
 383
 384 thp_swpout
 385         is incremented every time a huge page is swapout in one
 386         piece without splitting.
 387
 388 thp_swpout_fallback
 389         is incremented if a huge page has to be split before swapout.
 390         Usually because failed to allocate some continuous swap space
 391         for the huge page.
 392
 393 As the system ages, allocating huge pages may be expensive as the
 394 system uses memory compaction to copy data around memory to free a
 395 huge page for use. There are some counters in ``/proc/vmstat`` to help
 396 monitor this overhead.
 397
 398 compact_stall
 399         is incremented every time a process stalls to run
 400         memory compaction so that a huge page is free for use.
 401
 402 compact_success
 403         is incremented if the system compacted memory and
 404         freed a huge page for use.
 405
 406 compact_fail
 407         is incremented if the system tries to compact memory
 408         but failed.
 409
 410 It is possible to establish how long the stalls were using the function
 411 tracer to record how long was spent in __alloc_pages() and
 412 using the mm_page_alloc tracepoint to identify which allocations were
 413 for huge pages.
 414
 415 Optimizing the applications
 416 ===========================
 417
 418 To be guaranteed that the kernel will map a 2M page immediately in any
 419 memory region, the mmap region has to be hugepage naturally
 420 aligned. posix_memalign() can provide that guarantee.
 421
 422 Hugetlbfs
 423 =========
 424
 425 You can use hugetlbfs on a kernel that has transparent hugepage
 426 support enabled just fine as always. No difference can be noted in
 427 hugetlbfs other than there will be less overall fragmentation. All
 428 usual features belonging to hugetlbfs are preserved and
 429 unaffected. libhugetlbfs will also work fine as usual.