From: James Bottomley <James.Bottomley@SteelEye.com>
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.

-

This all sounds wonderful, and also means that if/when ARM starts

implementing highmem, kmap becomes useful.  (When I looked at that

a while back, adding the necessary flushes where required would mean
You'd still want to do the flushing on ARM because it's mostly VIVT.

Remapping pages with VIVT would just makes things much worse.
So yes, this sounds like a great idea.
--

Russell King

 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/

 maintainer of:

-