From: James Bottomley <James.Bottomley@SteelEye.com>
Date: Mon, 01 Jan 2007 10:34:12 -0600

quoted text
> 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.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/