On 2019/3/14 下午6:42, Michael S. Tsirkin wrote:
Which means after we fix vhost to add the flush_dcache_page after
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).
What double hit? If there's no cache to flush then cache flush is
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.
I've heard people complaining that on some microarchitectures even
no-op cache flushes are relatively expensive. Don't ask me why,
but if we can easily avoid double flushes we should do that.
It's still not entirely free for us. Our internal cache line is around
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
I suspect we'll keep the copyXuser path around for 32 bit anyway -
right Jason?
Yes since we don't want to slow down 32bit.
Thanks
So we can also keep using that on parisc...
--
