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 61096C00A89 for ; Fri, 30 Oct 2020 20:34:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AC2C420791 for ; Fri, 30 Oct 2020 20:34:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="J8d/YD59" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC2C420791 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 943886B0036; Fri, 30 Oct 2020 16:34:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E7276B005C; Fri, 30 Oct 2020 16:34:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 747D06B005D; Fri, 30 Oct 2020 16:34:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id 4341C6B0036 for ; Fri, 30 Oct 2020 16:34:28 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D5E8B180AD804 for ; Fri, 30 Oct 2020 20:34:27 +0000 (UTC) X-FDA: 77429744574.19.dogs84_3f0fbb427299 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id B94BE1AD1B1 for ; Fri, 30 Oct 2020 20:34:27 +0000 (UTC) X-HE-Tag: dogs84_3f0fbb427299 X-Filterd-Recvd-Size: 6189 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Fri, 30 Oct 2020 20:34:27 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id y16so8319184ljk.1 for ; Fri, 30 Oct 2020 13:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kjos0+S2Gon+fH3b26doFlCP2cxrfT62BjLoezK4rG4=; b=J8d/YD59wQ/au5l1BQ7ue2vwfU1yPmEzaWIbs72/a3aDX73KGLSsh/e6e4T2ilr+m6 v7YctKloyJWKSYk1q7y81pi983c4f8E7/f/kLdP0CFwMkO7uyjtkdfJgwTbIAUd3yTgV b5YrSxtLonkg9fnewHN7YslOk1fl6e5oIhge0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kjos0+S2Gon+fH3b26doFlCP2cxrfT62BjLoezK4rG4=; b=SV9GRD3qrrA7zpZKmWML8viU9Dt819X+hk+Ym9QhBKN6cUvUBHxEBvJyKHJOzEMvhi 1HnTZbcdJtOEJZqy4L5xC9YJMdoMlVAWsDNaZoL6bvjAAaM8d3AC7D8vDi1BsrNpWKI5 ttV7blVUP5pb41qtFpYsGBg++/ZBnXv2NTHUprnWR34mZdMBq6Poc6Kc2Kg0G80lupKH 9We08yAX3sNMVIgQWPuPwARR0ikPW17l+hQF5VRN1etTcERxKb7RvrsC/7BjRwNC9vxV SyzJYaRdVFYqeprSfzysY7MMk8DPZyXmm+E7iQ0Vy+WpBe8u4Bv11Bp2SX3sc3tOGNPL vT0w== X-Gm-Message-State: AOAM531/LvJNY2YBcFwv/RBUukHOTc/CzGDAItnY+tbYaRQAJZGvWHSp iPUWe7auDbtuoRzJESMbzCsZb1Q1ssEkEQ== X-Google-Smtp-Source: ABdhPJzEyv/JtsxNOahC+mVrvALLFuq9ARROfIJh6JHZ7nWELHCR7tvD5rDRKwBrTClkK+wtW7LwuA== X-Received: by 2002:a2e:9988:: with SMTP id w8mr1756788lji.107.1604090065344; Fri, 30 Oct 2020 13:34:25 -0700 (PDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id k28sm791153ljc.72.2020.10.30.13.34.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Oct 2020 13:34:25 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id h6so9513154lfj.3 for ; Fri, 30 Oct 2020 13:34:24 -0700 (PDT) X-Received: by 2002:a2e:760a:: with SMTP id r10mr1661953ljc.421.1604089720167; Fri, 30 Oct 2020 13:28:40 -0700 (PDT) MIME-Version: 1.0 References: <20201029221806.189523375@linutronix.de> <87pn50ob0s.fsf@nanos.tec.linutronix.de> <87blgknjcw.fsf@nanos.tec.linutronix.de> In-Reply-To: <87blgknjcw.fsf@nanos.tec.linutronix.de> From: Linus Torvalds Date: Fri, 30 Oct 2020 13:28:24 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends To: Thomas Gleixner 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 Content-Type: text/plain; charset="UTF-8" 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 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. It's been a bit of a pain to have kmap_atomic() have magical side semantics that people might then depend on. 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). I dunno. Linus