[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <91f708ed-f456-dc83-281e-fc18a0b4b981@nvidia.com>
Date: Sun, 14 Aug 2022 05:25:30 +0000
From: Chaitanya Kulkarni <chaitanyak@...dia.com>
To: "ira.weiny@...el.com" <ira.weiny@...el.com>,
Andy Whitcroft <apw@...onical.com>,
Joe Perches <joe@...ches.com>
CC: "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
"kgdb-bugreport@...ts.sourceforge.net"
<kgdb-bugreport@...ts.sourceforge.net>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
"dm-devel@...hat.com" <dm-devel@...hat.com>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux1394-devel@...ts.sourceforge.net"
<linux1394-devel@...ts.sourceforge.net>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
"Fabio M . De Francesco" <fmdefrancesco@...il.com>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
"linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
Thomas Gleixner <tglx@...utronix.de>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-raid@...r.kernel.org" <linux-raid@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] checkpatch: Add kmap and kmap_atomic to the deprecated
list
On 8/13/22 15:00, ira.weiny@...el.com wrote:
> From: Ira Weiny <ira.weiny@...el.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@...utronix.de>
> Suggested-by: Fabio M. De Francesco <fmdefrancesco@...il.com>
> Signed-off-by: Ira Weiny <ira.weiny@...el.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@...dia.com>
Powered by blists - more mailing lists