Messages in this thread | | | Subject | Re: [RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap() | From | Jason Wang <> | Date | Thu, 14 Mar 2019 21:49:03 +0800 |
| |
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... > > --
| |