Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE
From: Nicholas Piggin <npiggin@gmail.com>
Date: 2018-08-27 08:05:11
Also in:
lkml
On Mon, 27 Aug 2018 09:47:01 +0200 Peter Zijlstra [off-list ref] wrote:
On Mon, Aug 27, 2018 at 03:00:08PM +1000, Nicholas Piggin wrote:quoted
On Fri, 24 Aug 2018 13:39:53 +0200 Peter Zijlstra [off-list ref] wrote:quoted
On Fri, Aug 24, 2018 at 01:32:14PM +0200, Peter Zijlstra wrote:quoted
quoted
quoted
Hurm.. look at commit: e77b0852b551 ("mm/mmu_gather: track page size with mmu gather and force flush if page size change")Ah, good, it seems that already got cleaned up a lot. But it all moved into the power code.. blergh.I lost track of what the problem is here?Aside from the commit above being absolute crap (which did get fixed up, luckily) I would really like to get rid of all arch specific mmu_gather. We can have opt-in bits to the generic code, but the endless back and forth between common and arch code is an utter pain in the arse. And there's only like 4 architectures that still have a custom mmu_gather: - sh - arm - ia64 - s390 sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf arch/ia64' leaving us with s390.
Well I don't see a big problem in having an arch_mmu_gather field or small bits. powerpc would actually like that rather than trying to add things it wants into generic code (and it wants more than just a few flags bits, ideally).
After that everyone uses the common code and we can clean up.quoted
For powerpc, tlb_start_vma is not the right API to use for this because it wants to deal with different page sizes within a vma.Yes.. I see that. tlb_remove_check_page_size_change() really is a rather ugly thing, it can cause loads of TLB flushes. Do you really _have_ to do that? The way ARM and x86 work is that using INVLPG in a 4K stride is still correct for huge pages, inefficient maybe, but so is flushing every other page because 'sparse' transparant-huge-pages.
It could do that. It requires a tlbie that matches the page size, so it means 3 sizes. I think possibly even that would be better than current code, but we could do better if we had a few specific fields in there. Thanks, Nick