On Tue, 2010-03-02 at 23:33 +0000, Benjamin Herrenschmidt wrote: > On Tue, 2010-03-02 at 17:47 +0000, Catalin Marinas wrote: > > > > Actually, option 2 still has an issue - does not easily work on SMP > > systems where cache maintenance operations aren't broadcast in hardware. > > In this case (ARM11MPCore), flush_dcache_page() is implemented > > non-lazily so that the flushing happens on the same processor that > > dirtied the cache. But since with some drivers there is no call to this > > function, it wouldn't make any difference. > > Also, option 1 would not solve the icache issue which has the same > problem related to IPIs. Correct. But that's true for both options. It would have been simpler if we had software TLBs. > You -really- need to spank some HW folks here :-) I think they got the message :). Cortex-A9 does it properly. > > A solution is to do something like read-for-ownership before flushing > > the D-cache in update_mmu_cache() (or set_pte_at()). > > You might also want to experiment with not clearing PG_arch_1 in > flush_dcache_page(). I'm not 100% convinced it is necessary and that may > reduce the amount of flushing needed. Could a file map page be swapped out (and the mapping removed), then the page cache page modified (i.e. NFS filesystem) and flush_dcache_page() called? > Another thing is, on powerpc, we only do the cleaning when we try to > execute from the pages. IE. We basically "filter out" exec permission > when pages are not clean. At least on processors that support per-page > exec permission. You may want to consider something like that as well. For non-aliasing VIPT, I think that's a fair optimisation. Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
