On Wed, Nov 19, 2014 at 08:07:59AM +0000, Naoya Horiguchi wrote: > 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 <[email protected]> > > --- > > 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?
I'll update documentation futher once patchset will be closer to ready state. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
