docs/vm: transhuge: minor updates
Some formatting changes and addition of a sentence introducing khugepaged Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Родитель
07a83038a3
Коммит
aa00eaa9af
|
@ -9,14 +9,19 @@ Objective
|
||||||
|
|
||||||
Performance critical computing applications dealing with large memory
|
Performance critical computing applications dealing with large memory
|
||||||
working sets are already running on top of libhugetlbfs and in turn
|
working sets are already running on top of libhugetlbfs and in turn
|
||||||
hugetlbfs. Transparent Hugepage Support is an alternative means of
|
hugetlbfs. Transparent HugePage Support (THP) is an alternative mean of
|
||||||
using huge pages for the backing of virtual memory with huge pages
|
using huge pages for the backing of virtual memory with huge pages
|
||||||
that supports the automatic promotion and demotion of page sizes and
|
that supports the automatic promotion and demotion of page sizes and
|
||||||
without the shortcomings of hugetlbfs.
|
without the shortcomings of hugetlbfs.
|
||||||
|
|
||||||
Currently it only works for anonymous memory mappings and tmpfs/shmem.
|
Currently THP only works for anonymous memory mappings and tmpfs/shmem.
|
||||||
But in the future it can expand to other filesystems.
|
But in the future it can expand to other filesystems.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
in the examples below we presume that the basic page size is 4K and
|
||||||
|
the huge page size is 2M, although the actual numbers may vary
|
||||||
|
depending on the CPU architecture.
|
||||||
|
|
||||||
The reason applications are running faster is because of two
|
The reason applications are running faster is because of two
|
||||||
factors. The first factor is almost completely irrelevant and it's not
|
factors. The first factor is almost completely irrelevant and it's not
|
||||||
of significant interest because it'll also have the downside of
|
of significant interest because it'll also have the downside of
|
||||||
|
@ -28,15 +33,27 @@ only matters the first time the memory is accessed for the lifetime of
|
||||||
a memory mapping. The second long lasting and much more important
|
a memory mapping. The second long lasting and much more important
|
||||||
factor will affect all subsequent accesses to the memory for the whole
|
factor will affect all subsequent accesses to the memory for the whole
|
||||||
runtime of the application. The second factor consist of two
|
runtime of the application. The second factor consist of two
|
||||||
components: 1) the TLB miss will run faster (especially with
|
components:
|
||||||
virtualization using nested pagetables but almost always also on bare
|
|
||||||
metal without virtualization) and 2) a single TLB entry will be
|
1) the TLB miss will run faster (especially with virtualization using
|
||||||
mapping a much larger amount of virtual memory in turn reducing the
|
nested pagetables but almost always also on bare metal without
|
||||||
number of TLB misses. With virtualization and nested pagetables the
|
virtualization)
|
||||||
TLB can be mapped of larger size only if both KVM and the Linux guest
|
|
||||||
are using hugepages but a significant speedup already happens if only
|
2) a single TLB entry will be mapping a much larger amount of virtual
|
||||||
one of the two is using hugepages just because of the fact the TLB
|
memory in turn reducing the number of TLB misses. With
|
||||||
miss is going to run faster.
|
virtualization and nested pagetables the TLB can be mapped of
|
||||||
|
larger size only if both KVM and the Linux guest are using
|
||||||
|
hugepages but a significant speedup already happens if only one of
|
||||||
|
the two is using hugepages just because of the fact the TLB miss is
|
||||||
|
going to run faster.
|
||||||
|
|
||||||
|
THP can be enabled system wide or restricted to certain tasks or even
|
||||||
|
memory ranges inside task's address space. Unless THP is completely
|
||||||
|
disabled, there is ``khugepaged`` daemon that scans memory and
|
||||||
|
collapses sequences of basic pages into huge pages.
|
||||||
|
|
||||||
|
The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
|
||||||
|
interface and using madivse(2) and prctl(2) system calls.
|
||||||
|
|
||||||
Transparent Hugepage Support maximizes the usefulness of free memory
|
Transparent Hugepage Support maximizes the usefulness of free memory
|
||||||
if compared to the reservation approach of hugetlbfs by allowing all
|
if compared to the reservation approach of hugetlbfs by allowing all
|
||||||
|
@ -69,9 +86,14 @@ Applications that gets a lot of benefit from hugepages and that don't
|
||||||
risk to lose memory by using hugepages, should use
|
risk to lose memory by using hugepages, should use
|
||||||
madvise(MADV_HUGEPAGE) on their critical mmapped regions.
|
madvise(MADV_HUGEPAGE) on their critical mmapped regions.
|
||||||
|
|
||||||
|
.. _thp_sysfs:
|
||||||
|
|
||||||
sysfs
|
sysfs
|
||||||
=====
|
=====
|
||||||
|
|
||||||
|
Global THP controls
|
||||||
|
-------------------
|
||||||
|
|
||||||
Transparent Hugepage Support for anonymous memory can be entirely disabled
|
Transparent Hugepage Support for anonymous memory can be entirely disabled
|
||||||
(mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
|
(mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
|
||||||
regions (to avoid the risk of consuming more memory resources) or enabled
|
regions (to avoid the risk of consuming more memory resources) or enabled
|
||||||
|
@ -142,6 +164,9 @@ khugepaged will be automatically started when
|
||||||
transparent_hugepage/enabled is set to "always" or "madvise, and it'll
|
transparent_hugepage/enabled is set to "always" or "madvise, and it'll
|
||||||
be automatically shutdown if it's set to "never".
|
be automatically shutdown if it's set to "never".
|
||||||
|
|
||||||
|
Khugepaged controls
|
||||||
|
-------------------
|
||||||
|
|
||||||
khugepaged runs usually at low frequency so while one may not want to
|
khugepaged runs usually at low frequency so while one may not want to
|
||||||
invoke defrag algorithms synchronously during the page faults, it
|
invoke defrag algorithms synchronously during the page faults, it
|
||||||
should be worth invoking defrag at least in khugepaged. However it's
|
should be worth invoking defrag at least in khugepaged. However it's
|
||||||
|
|
Загрузка…
Ссылка в новой задаче