On Wed, Apr 28, 2010 at 2:22 AM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > So we tried to speed things up a bit using flush_hash_pages() directly > but that falls over on 603 of course meaning we fail to flush the TLB > properly and we may even end up having it corrupt memory randomly by > accessing a hash table that doesn't exist. > > This removes the "optimization" by always going through flush_tlb_page() > for now at least. > > Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- > > Somebody with a 603 or e300 core based FSL SoC to try this out for me ? > > It's obviously completely untested :-) > > Cheers, > Ben. > > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c > index b9243e7..95774b4 100644 > --- a/arch/powerpc/mm/pgtable_32.c > +++ b/arch/powerpc/mm/pgtable_32.c > @@ -385,11 +385,7 @@ static int __change_page_attr(struct page *page, > pgprot_t prot) > return -EINVAL; > __set_pte_at(&init_mm, address, kpte, mk_pte(page, prot), 0); > wmb(); > -#ifdef CONFIG_PPC_STD_MMU > - flush_hash_pages(0, address, pmd_val(*kpmd), 1); > -#else > flush_tlb_page(NULL, address); > -#endif > pte_unmap(kpte); > > return 0; > > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > This change works me on a 834x(e300) platform, tested with lmbench and a production-ready application with 2.6.33.3.
Xianghua _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
