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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55B11BE1.3070903@intel.com>
Date:	Thu, 23 Jul 2015 09:52:49 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
CC:	Catalin Marinas <catalin.marinas@....com>,
	David Rientjes <rientjes@...gle.com>,
	linux-mm <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: Flush the TLB for a single address in a huge page

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!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/