On Thu, 2012-02-16 at 11:11 -0600, Seth Jennings wrote: > Just wanted to bump you again about this. You mentioned that if I wanted to > do a cpu-local flush of a single tlb entry, that there would have to be a new > hook. Is that right? > > I've been looking through the powerpc arch and I thought that I might have > found the power analog to __flush_tlb_one() for x86 in local_flush_tlb_page() > with a NULL vma argument. This doesn't seem to work though, as indicated > by a crash when I tried it. After looking in tlbflush.h again, it seems > that local_flush_tlb_page() is a no-op when CONFIG_PPC_STD_MMU_64 is set, > as are almost ALL of the tlb flushing functions... which makes no sense to > me. > > Any help you (or anyone) can give me would be greatly appreciated.
On ppc64 with hash-table MMU, we handle the flushes very differently. PTEs that are modified are added to a list at the time of the modification and either flushed immediately if no lazy tlb batching is in progress or flushed when leaving the lazy tlb op. This is to avoid a problem where we might otherwise, under some circumstances, create a new TLB which can be hashed in to the hash table before the previous one has been flushed out. That would lead to a dup in the hash table which is architecturally illegal. This happens via the call to hpte_need_flush() in pte_update(). Unfortunately, it will always consider all kernel mappings as global, so the per-cpu "optimization" won't be usable in this case, at least not until we add some kind of additional argument to that function. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
