On Thu, 2010-03-04 at 22:11 +0000, Catalin Marinas wrote: > On Thu, 2010-03-04 at 21:37 +0000, Benjamin Herrenschmidt wrote: > > On Thu, 2010-03-04 at 18:07 +0000, Catalin Marinas wrote: > > > I'm not familiar with SH but for PIO devices the flushing shouldn't be > > > more aggressive. For the DMA devices, Russell suggested that we mark > > > the page as clean (set PG_dcache_clean) in the DMA API to avoid the > > > default flushing. > > > > I really like that idea, as I said earlier, but I'm worried about the I$ > > side of things. IE. What I'm trying to say is that I can't see how to do > > that optimisation without ending up with missing I$ invalidations or > > doing way too many of them, unless we have a separate bit to track I$ > > state. > > But does this optimisation really matter? I think with careful checking > in set_pte_at(), you are not going to invalidate the I-cache more than > necessary. If the original page wasn't pte_present() you would need to > do the I-cache invalidation. The other cases where set_pte_at() is > called for LRU (pte_young) or COW (pte_write) we can avoid the extra > invalidation. No. Not on PIPT (or non aliasing VIPT). Take your typical glibc text page. This is a struct page that will be mapped in almost every process in your system. You do not want to do the icache inval every time. Once it's been cleaned once, it's clean for subsequent mappings. Only VIVT needs such multiple invalidates I suppose though in this case you probably do everything differently anyways. Cheers, Ben. -- 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
