From: James Bottomley <[EMAIL PROTECTED]> Date: Mon, 01 Jan 2007 10:34:12 -0600
> Erm, well the whole reason for the flush_anon_pages() was that you told > me not to do it in flush_dcache_page() ... > > Although this is perhaps part of the confusion over what > flush_dcache_page() is actually supposed to do. I completely agree, it's confusing. I've tried to make it "just a hook" where architectures do whatever is necessary at that point to synchronize things. It's a poor definition and gives the implementor not much more than a rope with which to hang themselves :-) That's why I'm thinking strongly about perhaps encouraging people to go the kmap() route. It would avoid all the flushing in exchange for some specialized TLB accesses. If the flushes are really expensive, and the TLB operations to setup/teardown the kmap()'s can be relatively cheap, it might be the thing to do on PARISC. More and more I like Ralf's kmap() approach because you only do things exactly where the kernel actually touches the page. And if it would really help in some way, we can even tag the kmap() calls with "KMAP_READ" or "KMAP_WRITE" type attributes as appropriate. Because let's say you don't want to do the TLB mapping thing, and still want to actually cache flush, then this hint about the access could guide what kind of flush you do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/