[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()

Jason Wang
2019-03-14T13:49:03Z

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...
>
> --