From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29A54C00A89 for ; Fri, 30 Oct 2020 22:26:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8363322227 for ; Fri, 30 Oct 2020 22:26:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="LxHJ68FH"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="2rJuYiPt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8363322227 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 86CD76B0036; Fri, 30 Oct 2020 18:26:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81CBD6B005C; Fri, 30 Oct 2020 18:26:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70B656B005D; Fri, 30 Oct 2020 18:26:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 41A536B0036 for ; Fri, 30 Oct 2020 18:26:39 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 35C0C3626 for ; Fri, 30 Oct 2020 22:26:37 +0000 (UTC) X-FDA: 77430027234.16.men60_191012e27299 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 16A1C100E6903 for ; Fri, 30 Oct 2020 22:26:37 +0000 (UTC) X-HE-Tag: men60_191012e27299 X-Filterd-Recvd-Size: 5852 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 22:26:36 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1604096793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=26Ts76LEb5dF8UM0hmSIHaJpUqiGiJWBHMp5iFf7PiU=; b=LxHJ68FH0YuIEFWx2pJpQimCZfTiqoGgDDau1FguLxRy0zRx9jDZctdAlFRJ324v8CuoYi ZcuxU/DPzAwKZjuk1f5n85YkZURSL9nRFHt8mfu6t3it4VWyE7SlneV0erS9MR7nX9FzlP P+HNof6Xh5RpyyaWT992LVmq2zyMt7WHQ/M2MkeRhrztzkZ4okq5IzkTTD/fUPiSmr0pHZ BD6hj5xP7axA2OIEeQSYPyXK4XbM9OHuPNmPWTriLFFXeAcRngKo5tuvQR0c5M5uRZiaiR 7vOFKe6AAtTBf3UuZjT2hn26v4yx6tPJ2p6ldMkYWP3ZaJp8ZxNVmOK4vPxpMA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1604096793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=26Ts76LEb5dF8UM0hmSIHaJpUqiGiJWBHMp5iFf7PiU=; b=2rJuYiPt20Oowm+h+GqzEiWNX0OgtYb09gN+zSFDN57qQiTBtXhd6AncITU48GjmrMPQTD wElJt4hkBKleVUBg== To: Linus Torvalds Cc: LKML , linux-arch , Peter Zijlstra , Paul McKenney , David Airlie , Daniel Vetter , Ard Biesheuvel , Herbert Xu , Christoph Hellwig , Sebastian Andrzej Siewior , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Andrew Morton , Linux-MM , the arch/x86 maintainers , Vineet Gupta , "open list\:SYNOPSYS ARC ARCHITECTURE" , Russell King , Arnd Bergmann , Linux ARM , Guo Ren , linux-csky@vger.kernel.org, Michal Simek , Thomas Bogendoerfer , linux-mips@vger.kernel.org, Nick Hu , Greentime Hu , Vincent Chen , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev , "David S. Miller" , linux-sparc , Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org,Matthew Wilcox Subject: Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends In-Reply-To: References: <20201029221806.189523375@linutronix.de> <87pn50ob0s.fsf@nanos.tec.linutronix.de> <87blgknjcw.fsf@nanos.tec.linutronix.de> Date: Fri, 30 Oct 2020 23:26:33 +0100 Message-ID: <87sg9vl59i.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 30 2020 at 13:28, Linus Torvalds wrote: > On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote: >> >> 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. > > So the main reason I'd like to see it is because I think on a > non-highmem machine, the new kmap should be a complete no-op. IOW, > we'd make sure that there are no costs, no need to increment any > "restrict migration" counts etc. Fair enough. > It's been a bit of a pain to have kmap_atomic() have magical side > semantics that people might then depend on. kmap_atomic() will still have the side semantics :) > I think "local" could still work as a name, because it would have to > be thread-local (and maybe we'd want a debug mode where that gets > verified, as actual HIGHMEM machines are getting rare). > > I'd avoid "task", because that implies (to me, at least) that it > wouldn't be good for interrupts etc that don't have a task context. > > I think the main issue is that it has to be released in the same > context as it was created (ie no passing those things around to other > contexts). I think "local" is fine for that, but I could imagine other > names. The ones that come to mind are somewhat cumbersome, though > ("shortterm" or "local_ctx" or something along those lines). Yeah, not really intuitive either. Let's stick with _local and add proper function documentation which clearly says, that the side effect of non-migratability applies only for the 32bit highmem case in order to make it work at all. So code which needs CPU locality cannot rely on it and we have enough debug stuff to catch something like: kmap_local() this_cpu_write(....) kunmap_local() Let me redo the pile. While at it I might have a look at that debug request from Willy in the other end of this thread. Any comment on that? https://lore.kernel.org/r/87k0v7mrrd.fsf@nanos.tec.linutronix.de Thanks, tglx