I suspect we'll keep the copyXuser path around for 32 bit anyway -It's still not entirely free for us. Our internal cache line is aroundI've heard people complaining that on some microarchitectures evenWhich means after we fix vhost to add the flush_dcache_page afterWhat double hit? If there's no cache to flush then cache flush is
kunmap, Parisc will get a double hit (but it also means Parisc
was the only one of those archs needed explicit cache flushes,
where vhost worked correctly so far.. so it kinds of proofs your
point of giving up being the safe choice).
a no-op. It's also a highly piplineable no-op because the CPU has
the L1 cache within easy reach. The only event when flush takes a
large amount time is if we actually have dirty data to write back
to main memory.
no-op cache flushes are relatively expensive. Don't ask me why,
but if we can easily avoid double flushes we should do that.
32 bytes (some have 16 and some have 64) but that means we need 128
flushes for a page ... we definitely can't pipeline them all. So I
agree duplicate flush elimination would be a small improvement.
James
right Jason?
So we can also keep using that on parisc...
--