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

From: Chaitanya Kulkarni
Date: Sun Aug 14 2022 - 01:25:52 EST


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>