From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Juri Lelli <juri.lelli@redhat.com>,
linux-xtensa@linux-xtensa.org,
Peter Zijlstra <peterz@infradead.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-mips@vger.kernel.org, Ben Segall <bsegall@google.com>,
Linux-MM <linux-mm@kvack.org>, Guo Ren <guoren@kernel.org>,
linux-sparc <sparclinux@vger.kernel.org>,
Vincent Chen <deanbo422@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
the arch/x86 maintainers <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
linux-csky@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
David Airlie <airlied@linux.ie>, Mel Gorman <mgorman@suse.de>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
Ard Biesheuvel <ardb@kernel.org>,
Paul McKenney <paulmck@kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Steven Rostedt <rostedt@goodmis.org>,
Greentime Hu <green.hu@gmail.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Chris Zankel <chris@zankel.net>, Michal Simek <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
Vineet Gupta <vgupta@synopsys.com>,
LKML <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Daniel Vetter <daniel@ffwll.ch>,
Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends
Date: Fri, 30 Oct 2020 10:39:11 +0100 [thread overview]
Message-ID: <87blgknjcw.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87pn50ob0s.fsf@nanos.tec.linutronix.de>
On Fri, Oct 30 2020 at 00:41, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote:
> No, you're not misreading it, but doing it conditionally would be a
> complete semantical disaster. kmap_atomic*() also disables preemption
> and pagefaults unconditionaly. If that wouldn't be the case then every
> caller would have to have conditionals like 'if (CONFIG_HIGHMEM)' or
> worse 'if (PageHighMem(page)'.
>
> Let's not go there.
>
> Migrate disable is a less horrible plague than preempt and pagefault
> disable even if the scheduler people disagree due to the lack of theory
> backing that up :)
>
> The charm of the new interface is that users still can rely on per
> cpuness independent of being on a highmem plagued system. For non
> highmem systems the extra migrate disable/enable is really a minor
> nuissance.
thinking about it some more after having sleep and coffee, we actually
could hide the migrate disable in the actual highmem part.
But then we really should not name it kmap_local. 'local' suggests
locality, think local_irq*, local_bh* ... kmap_task would be more
accurate then.
Toughts?
tglx
next prev parent reply other threads:[~2020-10-30 9:41 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 22:18 [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends Thomas Gleixner
2020-10-29 22:18 ` [patch V2 01/18] sched: Make migrate_disable/enable() independent of RT Thomas Gleixner
2020-10-29 22:18 ` [patch V2 02/18] mm/highmem: Un-EXPORT __kmap_atomic_idx() Thomas Gleixner
2020-10-29 22:18 ` [patch V2 03/18] highmem: Provide generic variant of kmap_atomic* Thomas Gleixner
2020-10-29 23:46 ` Test Results: RE: [V2,03/18] " snowpatch
2020-10-29 22:18 ` [patch V2 04/18] x86/mm/highmem: Use generic kmap atomic implementation Thomas Gleixner
2020-10-29 22:18 ` [patch V2 05/18] arc/mm/highmem: " Thomas Gleixner
2020-10-29 23:44 ` Test Results: RE: [V2, " snowpatch
2020-10-29 22:18 ` [patch V2 06/18] ARM: highmem: Switch to generic kmap atomic Thomas Gleixner
2020-10-29 23:40 ` Test Results: RE: [V2,06/18] " snowpatch
2020-10-29 22:18 ` [patch V2 07/18] csky/mm/highmem: " Thomas Gleixner
2020-10-29 23:42 ` Test Results: RE: [V2, " snowpatch
2020-10-29 22:18 ` [patch V2 08/18] microblaze/mm/highmem: " Thomas Gleixner
2020-10-29 23:38 ` Test Results: RE: [V2,08/18] " snowpatch
2020-10-29 22:18 ` [patch V2 09/18] mips/mm/highmem: " Thomas Gleixner
2020-10-29 23:36 ` Test Results: RE: [V2, " snowpatch
2020-10-29 22:18 ` [patch V2 10/18] nds32/mm/highmem: " Thomas Gleixner
2020-10-29 23:33 ` Test Results: RE: [V2,10/18] " snowpatch
2020-10-29 22:18 ` [patch V2 11/18] powerpc/mm/highmem: " Thomas Gleixner
2020-10-29 23:31 ` Test Results: RE: [V2,11/18] " snowpatch
2020-10-29 22:18 ` [patch V2 12/18] sparc/mm/highmem: " Thomas Gleixner
2020-10-29 23:29 ` Test Results: RE: [V2,12/18] " snowpatch
2020-10-29 22:18 ` [patch V2 13/18] xtensa/mm/highmem: " Thomas Gleixner
2020-10-29 23:26 ` Test Results: RE: [V2,13/18] " snowpatch
2020-10-29 22:18 ` [patch V2 14/18] mm/highmem: Remove the old kmap_atomic cruft Thomas Gleixner
2020-10-29 23:22 ` Test Results: RE: [V2,14/18] " snowpatch
2020-10-29 22:18 ` [patch V2 15/18] io-mapping: Cleanup atomic iomap Thomas Gleixner
2020-10-29 23:20 ` Test Results: RE: [V2,15/18] " snowpatch
2020-10-29 22:18 ` [patch V2 16/18] sched: highmem: Store local kmaps in task struct Thomas Gleixner
2020-10-29 23:24 ` Test Results: RE: [V2,16/18] " snowpatch
2020-10-29 22:18 ` [patch V2 17/18] mm/highmem: Provide kmap_local* Thomas Gleixner
2020-10-29 23:18 ` Test Results: RE: [V2,17/18] " snowpatch
2020-10-29 22:18 ` [patch V2 18/18] io-mapping: Provide iomap_local variant Thomas Gleixner
2020-10-29 23:16 ` Test Results: RE: [V2,18/18] " snowpatch
2020-10-29 23:11 ` [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends Linus Torvalds
2020-10-29 23:41 ` Thomas Gleixner
2020-10-30 9:39 ` Thomas Gleixner [this message]
2020-10-30 20:28 ` Linus Torvalds
2020-10-30 22:26 ` Thomas Gleixner
2020-10-30 22:46 ` Linus Torvalds
2020-10-30 23:26 ` Thomas Gleixner
2020-10-30 23:53 ` Thomas Gleixner
2020-10-31 13:37 ` Arnd Bergmann
2020-10-31 15:05 ` Christophe Leroy
2020-10-31 21:33 ` Arnd Bergmann
2020-10-30 7:25 ` Christoph Hellwig
2020-10-30 9:39 ` Thomas Gleixner
2020-10-30 13:06 ` Matthew Wilcox
2020-10-30 19:35 ` Thomas Gleixner
2020-11-02 1:08 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87blgknjcw.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=chris@zankel.net \
--cc=daniel@ffwll.ch \
--cc=davem@davemloft.net \
--cc=deanbo422@gmail.com \
--cc=dietmar.eggemann@arm.com \
--cc=green.hu@gmail.com \
--cc=guoren@kernel.org \
--cc=hch@lst.de \
--cc=herbert@gondor.apana.org.au \
--cc=jcmvbkbc@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=monstr@monstr.eu \
--cc=nickhu@andestech.com \
--cc=paulmck@kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sparclinux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tsbogend@alpha.franken.de \
--cc=vgupta@synopsys.com \
--cc=vincent.guittot@linaro.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).