Messages in this thread | | | From | Nick Piggin <> | Subject | Re: kmap_atomic_pfn for PCI BAR access? | Date | Mon, 7 Jul 2008 21:19:10 +1000 |
| |
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)
| |