On 8/13/22 15:00, ira.weiny@xxxxxxxxx wrote: > From: Ira Weiny <ira.weiny@xxxxxxxxx> > > kmap() and kmap_atomic() are being deprecated in favor of > kmap_local_page(). > > There are two main problems with kmap(): (1) It comes with an overhead > as mapping space is restricted and protected by a global lock for > synchronization and (2) it also requires global TLB invalidation when > the kmap’s pool wraps and it might block when the mapping space is fully > utilized until a slot becomes available. > > kmap_local_page() is safe from any context and is therefore redundant > with kmap_atomic() with the exception of any pagefault or preemption > disable requirements. However, using kmap_atomic() for these side > effects makes the code less clear. So any requirement for pagefault or > preemption disable should be made explicitly. > > With kmap_local_page() the mappings are per thread, CPU local, can take > page faults, and can be called from any context (including interrupts). > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > the tasks can be preempted and, when they are scheduled to run again, > the kernel virtual addresses are restored. > > Suggested-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Suggested-by: Fabio M. De Francesco <fmdefrancesco@xxxxxxxxx> > Signed-off-by: Ira Weiny <ira.weiny@xxxxxxxxx> > > --- > Suggested by credits. > Thomas: Idea to keep from growing more kmap/kmap_atomic calls. > Fabio: Stole some of his boiler plate commit message. > > Notes on tree-wide conversions: > > I've cc'ed mailing lists for subsystems which currently contains either kmap() > or kmap_atomic() calls. As some of you already know Fabio and I have been > working through converting kmap() calls to kmap_local_page(). But there is a > lot more work to be done. Help from the community is always welcome, > especially with kmap_atomic() conversions. To keep from stepping on each > others toes I've created a spreadsheet of the current calls[1]. Please let me > or Fabio know if you plan on tacking one of the conversions so we can mark it > off the list. > > [1] https://docs.google.com/spreadsheets/d/1i_ckZ10p90bH_CkxD2bYNi05S2Qz84E2OFPv8zq__0w/edit#gid=1679714357 > Looks good. Reviewed-by: Chaitanya Kulkarni <kch@xxxxxxxxxx>
