lkml.org 
[lkml]   [2016]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHv8 26/32] thp: update Documentation/vm/transhuge.txt
From
Date
Hello Kirill,

On 12/05/16 16:41, Kirill A. Shutemov wrote:
> Add info about tmpfs/shmem with huge pages.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
> Documentation/vm/transhuge.txt | 130 +++++++++++++++++++++++++++++------------
> 1 file changed, 93 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> index d9cb65cf5cfd..96a49f123cac 100644
> --- a/Documentation/vm/transhuge.txt
> +++ b/Documentation/vm/transhuge.txt
> @@ -9,8 +9,8 @@ using huge pages for the backing of virtual memory with huge pages
> that supports the automatic promotion and demotion of page sizes and
> without the shortcomings of hugetlbfs.
>
> -Currently it only works for anonymous memory mappings but in the
> -future it can expand over the pagecache layer starting with tmpfs.
> +Currently it only works for anonymous memory mappings and tmpfs/shmem.
> +But in the future it can expand to other filesystems.
>
> The reason applications are running faster is because of two
> factors. The first factor is almost completely irrelevant and it's not
> @@ -48,7 +48,7 @@ miss is going to run faster.
> - if some task quits and more hugepages become available (either
> immediately in the buddy or through the VM), guest physical memory
> backed by regular pages should be relocated on hugepages
> - automatically (with khugepaged)
> + automatically (with khugepaged, limited to anonymous huge pages for now)

Is it still relevant? I think the patch #30 at the support for tmpfs/shmem.

[...]

> == Need of application restart ==
>
> -The transparent_hugepage/enabled values only affect future
> -behavior. So to make them effective you need to restart any
> -application that could have been using hugepages. This also applies to
> -the regions registered in khugepaged.
> +The transparent_hugepage/enabled values and tmpfs mount option only affect
> +future behavior. So to make them effective you need to restart any
> +application that could have been using hugepages. This also applies to the
> +regions registered in khugepaged.
>
> == Monitoring usage ==
>
> -The number of transparent huge pages currently used by the system is
> -available by reading the AnonHugePages field in /proc/meminfo. To
> -identify what applications are using transparent huge pages, it is
> -necessary to read /proc/PID/smaps and count the AnonHugePages fields
> -for each mapping. Note that reading the smaps file is expensive and
> -reading it frequently will incur overhead.
> +The number of anonymous transparent huge pages currently used by the
> +system is available by reading the AnonHugePages field in /proc/meminfo.
> +To identify what applications are using anonymous transparent huge pages,
> +it is necessary to read /proc/PID/smaps and count the AnonHugePages fields
> +for each mapping.
> +
> +The number of file transparent huge pages mapped to userspace is available
> +by reading the FileHugeMapped field in /proc/meminfo. To identify what
> +applications are mapping file transparent huge pages, it is necessary
> +to read /proc/PID/smaps and count the FileHugeMapped fields for each
> +mapping.

I cannot find the field FileHugeMapped in /proc/meminfo and
/proc/PID/smaps. However, there are 2 new fields ShmemHugePages and
ShmemPmdMapped.

Also I guess that filesystems/proc.txt has to be updated to explain the
new fields.

Regards,

--
Julien Grall

\
 
 \ /
  Last update: 2016-05-19 18:41    [W:0.385 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site