[PATCH] makedumpfile: Petr Tesarik's hugepage filtering
kumagai-atsushi at mxc.nes.nec.co.jp
Mon May 27 06:56:16 EDT 2013
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".
So I'd like to make the condition to estimate page type more restricted
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.
More information about the kexec