CPU-local TLB flushing

CPU-local TLB flushing

[Seth Jennings]

This is a continuation of a thread a few months ago:

https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-February/095775.html

zsmalloc is now in the staging tree and there are patches
on lkml to convert the x86 only tlb flushing code to arch
independent code.

https://lkml.org/lkml/2012/5/14/55

A quick back story, zsmalloc does some pte/tlb manipulation
to quickly map a pair of pages into a single VM area.  It
does this with interrupts disabled in a preallocated per-cpu
VM area, which means the mapping only exists in the TLB of
the cpu that does the mapping and, therefore, only needs to
be flushed on that same cpu during the unmapping process.

Right now, zsmalloc uses __flush_tlb_one() on x86 to do a
cpu-local single entry tlb flush.  Afaict, there is no such
call on ppc64.

The patch replaces that x86 call with a call to a new function,
local_unmap_kernel_range(), which is exactly the same as
unmap_kernel_range() in mm/vmalloc.c except that it calls
local_flush_tlb_kernel_range() instead of 
flush_tlb_kernel_range().

A few archs support local_flush_tlb_kernel_range() already and
another patch in the patchset above, introduces this function
for x86; basically a wrapper for __flush_tlb_single().

For PPC_STD_MMU_64, it looked like all the tlb flushing
functions were just stubs, so I just added a stub for
local_flush_tlb_kernel_range().  This was stable running
a single threaded application, bound to one cpu, but crashes
with even two threads.

With local_flush_tlb_kernel_range() being a stub,
the new function local_unmap_kernel_range() is exactly
the same as unmap_kernel_range() since 
local_flush_tlb_kernel_range() and flush_tlb_kernel_range()
are both stubs on ppc64.

My knowledge of the ppc64 hashing tlb design is almost
nothing, but it seems like this should work, albeit slowly
since it would be a global flush rather than cpu-local.

I was wondering if anyone could tell me why this doesn't work,
and what needs to be done to make it work.

Thanks in advance for any help!  Let me know if you need
clarification on something.

--
Seth

Re: CPU-local TLB flushing

[Michael Ellerman]

On Mon, 2012-06-18 at 15:55 -0500, Seth Jennings wrote:
> This is a continuation of a thread a few months ago:
...
> 
> With local_flush_tlb_kernel_range() being a stub,
> the new function local_unmap_kernel_range() is exactly
> the same as unmap_kernel_range() since 
> local_flush_tlb_kernel_range() and flush_tlb_kernel_range()
> are both stubs on ppc64.
> 
> My knowledge of the ppc64 hashing tlb design is almost
> nothing, but it seems like this should work, albeit slowly
> since it would be a global flush rather than cpu-local.
> 
> I was wondering if anyone could tell me why this doesn't work,
> and what needs to be done to make it work.

Hi Seth,

I don't know it that well either, but the way I think it should be
working is:

unmap_kernel_range()
 -> vunmap_page_range()
    -> vunmap_pud/pmd/pte_range()
       -> ptep_get_and_clear()		(arch/powerpc/include/asm/pgtable-ppc64.h)
          -> pte_update()		(arch/powerpc/include/asm/pgtable-ppc64.h)
	     -> hpte_need_flush()
		-> flush_hash_page()	(because you don't have a batch active - I assume)
		   -> pSeries_lpar_hpte_invalidate()


So step one would be to confirm you're getting that far, that would at
least confirm we are doing the invalidate.

cheers