Re: [PATCH] mm: Flush the TLB for a single address in a huge page

[Dave Hansen <dave.hansen@intel.com>]

On 07/23/2015 08:58 AM, Andrea Arcangeli wrote:
> You wrote the patch that uses the tlb_single_page_flush_ceiling, so if
> the above discussion would be relevant with regard to flush_tlb_page,
> are you implying that the above optimization in the kernel, should
> also be removed?

When I put that in, my goal was to bring consistency to how we handled
things without regressing anything.  I was never able to measure any
nice macro-level benefits to a particular flush behavior.

We can also now just easily disable the ranged flushes if we want to, or
leave them in place for small flushes only.

> When these flush_tlb_range optimizations were introduced, it was
> measured with benchmark that they helped IIRC. If it's not true
> anymore with latest CPU I don't know but there should be at least a
> subset of those CPUs where this helps. So I doubt it should be removed
> for all CPUs out there.

I tried to reproduce the results and had a difficult time doing so.

> The tlb_single_page_flush_ceiling optimization has nothing to do with
> 2MB pages. But if that is still valid (or if it has ever been valid
> for older CPUs), why is flush_tlb_page not a valid optimization at
> least for those older CPUS? Why is it worth doing single invalidates
> on 4k pages and not on 2MB pages?

I haven't seen any solid evidence that we should do it for one and not
the other.

> It surely was helpful to do invlpg invalidated on 4k pages, up to 33
> in a row, with x86 CPUs as you wrote the code quoted above to do
> that, and it is still in the current kernel. So why are 2MB pages
> different?

They were originally different because the work that introduced 'invlpg'
didn't see a benefit from using 'invlpg' on 2M pages.  I didn't
reevaluate it when I hacked on the code and just left it as it was.

It would be great if someone would go and collect some recent data on
using 'invlpg' on 2M pages!