On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter <dan...@ffwll.ch> wrote: > > On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner <t...@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.256266...@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.
(coffee just kicked in) copy_*_user is ofc allowed, but if you hit a page fault you get a short read/write. This looks like it would remove the need to handle these in a slowpath, since page faults can now be served in this new kmap_temporary sections. But this sounds too good to be true, so I'm wondering what I'm missing. -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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel