On Thu, Oct 06, 2022 at 03:29:35PM -0700, Hansen, Dave wrote: > On 10/6/22 15:02, Fabio M. De Francesco wrote: > > On Thursday, October 6, 2022 10:45:56 PM CEST Dave Hansen wrote: > > Am I still missing anything fundamental? > > Yes. :) > > kmap() users can sleep. That means the number of them that you need to > keep around is unbounded. kmap_atomic()'s fundamentally can't sleep so > you need fewer of them. That means that when you kunmap_atomic() you > can use a simple, fast, CPU-local TLB flushing operation. kunmap() > eventually requires a big fat global TLB flush. > > So, you're right. On lowmem-only systems, kmap() *can* be cheaper than > kmap_atomic(). But, on highmem systems there's no contest: > kmap_atomic() is king. > > That's why kmap_atomic() is and should be the default. But in the last few years optimizing lowmem systems has been the default. Few care about the performance of highmem systems. Given that we don't want to ever use kmap() nor kmap_atomic() going forward I think this discussion is purely academic. Ira
