Re: [PATCH 16/19] thp: update documentation
From: Naoya Horiguchi
Date: Wed Nov 19 2014 - 03:14:40 EST
On Wed, Nov 05, 2014 at 04:49:51PM +0200, Kirill A. Shutemov wrote:
> The patch updates Documentation/vm/transhuge.txt to reflect changes in
> THP design.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
> ---
> Documentation/vm/transhuge.txt | 84 +++++++++++++++++++-----------------------
> 1 file changed, 38 insertions(+), 46 deletions(-)
>
> diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> index df1794a9071f..33465e7b0d9b 100644
> --- a/Documentation/vm/transhuge.txt
> +++ b/Documentation/vm/transhuge.txt
> @@ -200,9 +200,18 @@ thp_collapse_alloc_failed is incremented if khugepaged found a range
> of pages that should be collapsed into one huge page but failed
> the allocation.
>
> -thp_split is incremented every time a huge page is split into base
> +thp_split_page is incremented every time a huge page is split into base
> pages. This can happen for a variety of reasons but a common
> reason is that a huge page is old and is being reclaimed.
> + This action implies splitting all PMD the page mapped with.
> +
> +thp_split_page_failed is is incremented if kernel fails to split huge
'is' appears twice.
> + page. This can happen if the page was pinned by somebody.
> +
> +thp_split_pmd is incremented every time a PMD split into table of PTEs.
> + This can happen, for instance, when application calls mprotect() or
> + munmap() on part of huge page. It doesn't split huge page, only
> + page table entry.
>
> thp_zero_page_alloc is incremented every time a huge zero page is
> successfully allocated. It includes allocations which where
There is a sentense related to the adjustment on futex code you just
removed in patch 15/19 in "get_user_pages and follow_page" section.
...
split_huge_page() to avoid the head and tail pages to disappear from
under it, see the futex code to see an example of that, hugetlbfs also
needed special handling in futex code for similar reasons).
this seems obsolete, so we need some change on this?
Thanks,
Naoya Horiguchi--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/