[Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
Daniel Vetter
daniel at ffwll.ch
Sat Sep 19 10:35:15 UTC 2020
On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner <tglx at linutronix.de> wrote:
>
> First of all, sorry for the horribly big Cc list!
>
> Following up to the discussion in:
>
> https://lore.kernel.org/r/20200914204209.256266093@linutronix.de
>
> this provides a preemptible variant of kmap_atomic & related
> interfaces. This is achieved by:
>
> - Consolidating all kmap atomic implementations in generic code
>
> - Switching from per CPU storage of the kmap index to a per task storage
>
> - Adding a pteval array to the per task storage which contains the ptevals
> of the currently active temporary kmaps
>
> - Adding context switch code which checks whether the outgoing or the
> incoming task has active temporary kmaps. If so, the outgoing task's
> kmaps are removed and the incoming task's kmaps are restored.
>
> - Adding new interfaces k[un]map_temporary*() which are not disabling
> preemption and can be called from any context (except NMI).
>
> Contrary to kmap() which provides preemptible and "persistant" mappings,
> these interfaces are meant to replace the temporary mappings provided by
> kmap_atomic*() today.
>
> This allows to get rid of conditional mapping choices and allows to have
> preemptible short term mappings on 64bit which are today enforced to be
> non-preemptible due to the highmem constraints. It clearly puts overhead on
> the highmem users, but highmem is slow anyway.
>
> This is not a wholesale conversion which makes kmap_atomic magically
> preemptible because there might be usage sites which rely on the implicit
> preempt disable. So this needs to be done on a case by case basis and the
> call sites converted to kmap_temporary.
>
> Note, that this is only lightly tested on X86 and completely untested on
> all other architectures.
>
> The lot is also available from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git highmem
I think it should be the case, but I want to double check: Will
copy_*_user be allowed within a kmap_temporary section? This would
allow us to ditch an absolute pile of slowpaths.
-Daniel
>
> Thanks,
>
> tglx
> ---
> a/arch/arm/mm/highmem.c | 121 ---------------------
> a/arch/microblaze/mm/highmem.c | 78 -------------
> a/arch/nds32/mm/highmem.c | 48 --------
> a/arch/powerpc/mm/highmem.c | 67 -----------
> a/arch/sparc/mm/highmem.c | 115 --------------------
> arch/arc/Kconfig | 1
> arch/arc/include/asm/highmem.h | 8 +
> arch/arc/mm/highmem.c | 44 -------
> arch/arm/Kconfig | 1
> arch/arm/include/asm/highmem.h | 30 +++--
> arch/arm/mm/Makefile | 1
> arch/csky/Kconfig | 1
> arch/csky/include/asm/highmem.h | 4
> arch/csky/mm/highmem.c | 75 -------------
> arch/microblaze/Kconfig | 1
> arch/microblaze/include/asm/highmem.h | 6 -
> arch/microblaze/mm/Makefile | 1
> arch/microblaze/mm/init.c | 6 -
> arch/mips/Kconfig | 1
> arch/mips/include/asm/highmem.h | 4
> arch/mips/mm/highmem.c | 77 -------------
> arch/mips/mm/init.c | 3
> arch/nds32/Kconfig.cpu | 1
> arch/nds32/include/asm/highmem.h | 21 ++-
> arch/nds32/mm/Makefile | 1
> arch/powerpc/Kconfig | 1
> arch/powerpc/include/asm/highmem.h | 6 -
> arch/powerpc/mm/Makefile | 1
> arch/powerpc/mm/mem.c | 7 -
> arch/sparc/Kconfig | 1
> arch/sparc/include/asm/highmem.h | 7 -
> arch/sparc/mm/Makefile | 3
> arch/sparc/mm/srmmu.c | 2
> arch/x86/include/asm/fixmap.h | 1
> arch/x86/include/asm/highmem.h | 12 +-
> arch/x86/include/asm/iomap.h | 29 +++--
> arch/x86/mm/highmem_32.c | 59 ----------
> arch/x86/mm/init_32.c | 15 --
> arch/x86/mm/iomap_32.c | 57 ----------
> arch/xtensa/Kconfig | 1
> arch/xtensa/include/asm/highmem.h | 9 +
> arch/xtensa/mm/highmem.c | 44 -------
> b/arch/x86/Kconfig | 3
> include/linux/highmem.h | 141 +++++++++++++++---------
> include/linux/io-mapping.h | 2
> include/linux/sched.h | 9 +
> kernel/sched/core.c | 10 +
> mm/Kconfig | 3
> mm/highmem.c | 192 ++++++++++++++++++++++++++++++++--
> 49 files changed, 422 insertions(+), 909 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list