Re: [PATCH v4 4/7] x86/tlb: fall back to flush all when meet a THPlarge page

From: Peter Zijlstra
Date: Fri May 11 2012 - 05:06:27 EST

On Fri, 2012-05-11 at 08:44 +0800, Alex Shi wrote:
> On 05/10/2012 06:40 PM, Borislav Petkov wrote:
> > On Thu, May 10, 2012 at 11:29:05AM +0200, Peter Zijlstra wrote:
> >> On Thu, 2012-05-10 at 13:00 +0800, Alex Shi wrote:
> >>> We don't need to flush large pages by PAGE_SIZE step, that just waste
> >>> time. and actually, large page don't need 'invlpg' optimizing according
> >>> to our macro benchmark. So, just flush whole TLB is enough for them.
> >>>
> >>> The following result is tested on a 2CPU * 4cores * 2HT NHM EP machine,
> >>> with THP 'always' setting.
> >>
> >> What does it do when you disable THP? That has_large_page() thing is a
> >> massive amount of pointer chasing..
> >
> > Yeah, this looks like a bit of a overhead. Don't we have some per-mm
> > accounting of whether that mm struct has hugepages in mm/huge_memory.c,
> > i.e. something like what collapse_huge_page() does, for example, at the
> > end by incrementing khugepaged_pages_collapsed but in a per-mm variable?
> >
> > And make this part of the THP code so we get it for free here.
> >
> > Is Andrea on the CC list... hm, no, CCed.
> Andrea has said there is no easy way to know if there is a large page in
> mm or vma.
> Actually, has_large_page just called only once, that due to the
> act_entries limit. But your opinion is worth to consider, the only one
> calling can be avoid if the 'start' address is not align on HPAGE_SIZE.

One possibility is to extend vm_flags and add have THP set a new flag
whenever it installs a new page. Then have mmu_gather collect this
vm_flag just like it collects VM_EXEC and VM_HUGETLB.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at