Re: kmap_atomic_pfn for PCI BAR access?

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Monday 07 July 2008 17:05, Arjan van de Ven wrote:
> On Mon, 7 Jul 2008 16:53:54 +1000

> > One thing I still haven't implemented in that patch are CPU-local
> > mappings (which only require a local flush to flush)... I found that
> > after the improvements I did implement, they didn't help much for
> > my workloads, so I suspect you might find the same thing...
>
> just to complicate things with ioremap() you have to deal with the
> various caching-coherency requirements.. making things lazy and per CPU
> complicates that a ton (and I suspect won't actually make things
> cheaper)

Yeah, my vmap rewrite has a vm_unmap_aliases() call, which the
page attribute code calls.

But these flushes are not really any different between the atomic
kmap area and my vmap lazy flushing: the atomic kmap code still
has to do a broadcast global TLB flush.

The fact is simply that changing cache attributes is always going
to be an expensive operation and lazy mappings are not going to
really change that -- because changing attributes is going to
require a TLB flush on all CPUs _anyway_, which is the expensive
thing. All we really have to do with lazy mappings is tear down
their page tables before CPA's TLB flush -- if there were no lazy
unmappings in that time, then there will be no extra work to do.

... or, it occurs to me that you might have been referring to
something else: the problem of simply changing the cache attributes
on the pages that you wish to ioremap now. That's going to be slow
sure, but these guys don't seem to need such an attribute change
anyway because they are using kmap_atomic_pfn (which doesn't change
attributes)