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

[Jason Wang]

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