I think we might be talking past each other. Let me try the double
flush first
On Tue, 2019-03-12 at 17:11 -0400, Andrea Arcangeli wrote:
> On Tue, Mar 12, 2019 at 01:53:37PM -0700, James Bottomley 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.
>
> The double hit is in parisc copy_to_user_page:
>
> #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
> do { \
> flush_cache_page(vma, vaddr, page_to_pfn(page)); \
> memcpy(dst, src, len); \
> flush_kernel_dcache_range_asm((unsigned long)dst, (unsigned
> long)dst + len); \
> } while (0)
>
> That is executed just before kunmap:
>
> static inline void kunmap(struct page *page)
> {
> flush_kernel_dcache_page_addr(page_address(page));
> }
I mean in the sequence
flush_dcache_page(page);
flush_dcache_page(page);
The first flush_dcache_page did all the work and the second it a
tightly pipelined no-op. That's what I mean by there not really being
a double hit.
James
