[PATCH] checkpatch: Add kmap and kmap_atomic to the deprecated list

Chaitanya Kulkarni chaitanyak at nvidia.com
Sun Aug 14 05:25:30 UTC 2022


On 8/13/22 15:00, ira.weiny at intel.com wrote:
> From: Ira Weiny <ira.weiny at intel.com>
> 
> 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 at linutronix.de>
> Suggested-by: Fabio M. De Francesco <fmdefrancesco at gmail.com>
> Signed-off-by: Ira Weiny <ira.weiny at intel.com>
> 
> ---
> 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 at nvidia.com>




More information about the dri-devel mailing list