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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150723171332.GD23799@redhat.com>
Date:	Thu, 23 Jul 2015 19:13:32 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Dave Hansen <dave.hansen@...el.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 Thu, Jul 23, 2015 at 09:55:33AM -0700, Dave Hansen wrote:
> On 07/23/2015 09:16 AM, Catalin Marinas wrote:
> > Anyway, if you want to keep the option of a full TLB flush for x86 on
> > huge pages, I'm happy to repost a v2 with a separate
> > flush_tlb_pmd_huge_page that arch code can define as it sees fit.
> 
> I think your patch is fine on x86.  We need to keep an eye out for any
> regressions, but I think it's OK.

That's my view as well.

I've read more of the other thread and I quote Ingo:

" It barely makes sense for a 2 pages and gets exponentially
worse. It's probably done in microcode and its performance is
horrible. "

So in our case it's just 1 page (not 2, not 33), and considering it
prevents to invalidate all other TLB entries, it's most certainly a
win: it requires zero additional infrastructure and best of all it can
also avoid to flush the entire TLB for remote CPUs too again without
infrastructure or pfn arrays or multiple invlpg.

As further confirmation that for 1 entry invlpg is worth it, even
flush_tlb_page->flush_tlb_func invokes __flush_tlb_single in the IPI
handler instead of local_flush_tlb().

So the discussion there was about the additional infrastructure and a
flood of invlpg, perhaps more than 33, I agree a local_flush_tlb()
sounds better for that.

The question left for x86 is if invlpg is even slower for 2MB pages
than it is for 4k pages, but I'd be surprised if it is, especially on
newer CPUs where the TLB can use different page size for each TLB
entry. Why we didn't do flush_tlb_page before wasn't related to such a
concern at least.
--
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/