[lkml]   [2019]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()

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.


> So we can also keep using that on parisc...
> --

 \ /
  Last update: 2019-03-14 14:50    [W:0.151 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site