On Thu, Jan 28, 2016 at 03:20:38PM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2016-01-27 at 21:13 +1100, David Gibson wrote: > > ppc_tlb_invalidate_one() has a big switch handling many different MMU > > types. However, most of those branches can never be reached: > > > > It is called from 3 places: from remove_hpte() and h_protect() in > > spapr_hcall.c (which always has a 64-bit hash MMU type), and from > > helper_tlbie() in mmu_helper.c. > > > > Calls to helper_tlbie() are generated from gen_tlbiel, gen_tlbiel and > > gen_tlbiva. The first two are only used with the PPC_MEM_TLBIE flag, > > set only with 32-bit or 64-bit hash MMU models, and gen_tlbiva() is > > used only on 440 and 460 models with the BookE mmu model. > > > > These means the exhaustive list of MMU types which may call > > ppc_tlb_invalidate_one() is: POWERPC_MMU_SOFT_6xx, POWERPC_MMU_601, > > POWERPC_MMU_32B, POWERPC_MMU_SOFT_74xx, POWERPC_MMU_64B, > > POWERPC_MMU_2_03, > > POWERPC_MMU_2_06, POWERPC_MMU_2_07 and POWERPC_MMU_BOOKE. > > > > Clean up by removing logic for all other MMU types from > > ppc_tlb_invalidate_one(). > > I would argue to move hash64 out of it as well anyway. First what we do > in there is dumb, but the way I change it with lazy inval differs and > tlbie does provide additional information on server processors that > we would need should we chose to implemented fine grained invalidations > (such as the page size).
I agree, but I didn't want to postpone the current things I'm working
on while I did that.
> In the meantime:
>
> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
