[PATCH] makedumpfile: Petr Tesarik's hugepage filtering

[Atsushi Kumagai]

On Fri, 24 May 2013 11:40:47 +0900
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote:

> (2013/05/24 11:24), HATAYAMA Daisuke wrote:
> > (2013/05/24 10:11), Atsushi Kumagai wrote:
> >> On Wed, 15 May 2013 13:43:59 -0500
> >> Cliff Wickman <cpw at sgi.com> wrote:
> 
> > Also, hugetlbfs pages are "user data". They should get filtered when user data dump level
> > is specified. So how about:
> >
> >        Dump  |  zero   without  with     user    free   hugetlbfs
> >        Level |  page   private  private  data    page   page
> >       -------+-----------------------------------------------------
> >           0  |
> >           1  |   X
> >           2  |           X
> >           4  |           X        X
> >           8  |                            X              X
> >          16  |                                    X
> >          32  |                                           X
> >          63  |   X       X        X       X       X      X
> >
> > On dump level 8, hugetlbfs pages also get filtered.
> 
> Thinking further, it might be unlikely that we want user data but don't want hugetlbfs pages
> on crash dump case. If so, I think Petr's implementation seems also OK. It seems no problem
> to postpone introducing new dump level after someone who wants to filter hugetlbfs pages only,
> actually occurs.

Even leaving aside the new dump level, I think his implementation needs
to be changed because the assumption that all compound pages are user
data will be broken by introducing "Transparent huge page cache".

  https://lkml.org/lkml/2013/5/11/187

So I'd like to make the condition to estimate page type more restricted
in advance.

As for user data on THP, they should be estimated using isAnon() and
isHugePage() combination like my code image.

But hugetlbfs pages don't meet isAnon(), so they should be estimated
with another logic like kernel's PageHuge().
And they can be filtered out as user data always.


Thanks
Atsushi Kumagai