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.9 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 7E6BAC43463 for ; Sat, 19 Sep 2020 17:27:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F35A620878 for ; Sat, 19 Sep 2020 17:27:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="PDwKTi4l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F35A620878 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 3B1616B0037; Sat, 19 Sep 2020 13:27:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 339636B0055; Sat, 19 Sep 2020 13:27:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DCC06B005A; Sat, 19 Sep 2020 13:27:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id 01E176B0037 for ; Sat, 19 Sep 2020 13:26:59 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BE0AC1F0A for ; Sat, 19 Sep 2020 17:26:59 +0000 (UTC) X-FDA: 77280491358.07.noise53_3614b2327135 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id A0EE41803F9AA for ; Sat, 19 Sep 2020 17:26:59 +0000 (UTC) X-HE-Tag: noise53_3614b2327135 X-Filterd-Recvd-Size: 7595 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Sat, 19 Sep 2020 17:26:59 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id k25so7658408ljk.0 for ; Sat, 19 Sep 2020 10:26:58 -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=waM6UyKAxKjxaPuk1aOj7tJ5Pe/ksOuiXEzSSo1PI/U=; b=PDwKTi4lX9j7zg3G7WzPyBOHBiLdhmAgWRxWPWvYR/nEys9FVfUL6zNUVgG09pDixg o+e2DCxbAvOZN3jBhyrOMZPfygh9RU8mogp2HXrCoLkUWHRL8e1VK4NRvgzXaMsluBfo GR1BPuNqLZOfJqo2g/IqA9gl4eqzfpV+zOYak= 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=waM6UyKAxKjxaPuk1aOj7tJ5Pe/ksOuiXEzSSo1PI/U=; b=p9/ybYjbU0Sq2zACz2ucRSU3oqTtJzttaRWJ8nWeCVfAMfWUHgPExP9S/DyLDr8LYa I9PoPA+MJVCOpZy4oK8BWTocgIRRZPQ2s9EF7YCfcyOdUj4uMFmxRHsq9nV6O3mD+eTC 5kLLYYYMEu/8WnAsc2g2COQws72lqQHhUnVl/b9IUcuP3XcQo59enwHGIigQ/NFFxTPd hppRqgwrh/gbyz8WDilLisEJp0EMmUEQTZRe/BlFTg1jbsNaFkxTpi9oqXyUV0F6FY0R WL8ONvKN921zswlgcu7RSJ9eWkbpXkHWgYXFaPrc1JwWVy5spF72In12nJd70SMAOqsE 9P3A== X-Gm-Message-State: AOAM5329V8X8N7KFGqh7xH1MnJRk1BPY0ij76kA+pS0ImCp5qTsTaKTd Xqb5IOObASWFdAFIdHenKP8azQFmXhK79g== X-Google-Smtp-Source: ABdhPJwD1GpSpipWr6v8sVtfS2TEHxdpe6GPyItuO+rPCj1F0WVfoqNEigy5wq+qYW+IPE8bTJ2ttA== X-Received: by 2002:a2e:b60b:: with SMTP id r11mr13348333ljn.415.1600536417147; Sat, 19 Sep 2020 10:26:57 -0700 (PDT) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com. [209.85.208.172]) by smtp.gmail.com with ESMTPSA id z8sm1375449ljh.19.2020.09.19.10.26.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Sep 2020 10:26:56 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id b19so7618426lji.11 for ; Sat, 19 Sep 2020 10:26:56 -0700 (PDT) X-Received: by 2002:a19:521a:: with SMTP id m26mr14134256lfb.133.1600535951025; Sat, 19 Sep 2020 10:19:11 -0700 (PDT) MIME-Version: 1.0 References: <20200919091751.011116649@linutronix.de> In-Reply-To: <20200919091751.011116649@linutronix.de> From: Linus Torvalds Date: Sat, 19 Sep 2020 10:18:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends To: Thomas Gleixner Cc: LKML , linux-arch , Paul McKenney , "the arch/x86 maintainers" , Sebastian Andrzej Siewior , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Andrew Morton , Linux-MM , Russell King , Linux ARM , Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx , dri-devel , Ard Biesheuvel , Herbert Xu , Vineet Gupta , "open list:SYNOPSYS ARC ARCHITECTURE" , Arnd Bergmann , 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 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 Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote: > > this provides a preemptible variant of kmap_atomic & related > interfaces. This is achieved by: Ack. This looks really nice, even apart from the new capability. The only thing I really reacted to is that the name doesn't make sense to me: "kmap_temporary()" seems a bit odd. Particularly for an interface that really is basically meant as a better replacement of "kmap_atomic()" (but is perhaps also a better replacement for "kmap()"). I think I understand how the name came about: I think the "temporary" is there as a distinction from the "longterm" regular kmap(). So I think it makes some sense from an internal implementation angle, but I don't think it makes a lot of sense from an interface name. I don't know what might be a better name, but if we want to emphasize that it's thread-private and a one-off, maybe "local" would be a better naming, and make it distinct from the "global" nature of the old kmap() interface? However, another solution might be to just use this new preemptible "local" kmap(), and remove the old global one entirely. Yes, the old global one caches the page table mapping and that sounds really efficient and nice. But it's actually horribly horribly bad, because it means that we need to use locking for them. Your new "temporary" implementation seems to be fundamentally better locking-wise, and only need preemption disabling as locking (and is equally fast for the non-highmem case). So I wonder if the single-page TLB flush isn't a better model, and whether it wouldn't be a lot simpler to just get rid of the old complex kmap() entirely, and replace it with this? I agree we can't replace the kmap_atomic() version, because maybe people depend on the preemption disabling it also implied. But what about replacing the non-atomic kmap()? Maybe I've missed something. Is it because the new interface still does "pagefault_disable()" perhaps? But does it even need the pagefault_disable() at all? Yes, the *atomic* one obviously needed it. But why does this new one need to disable page faults? [ I'm just reading the patches, I didn't try to apply them and look at the end result, so I might have missed something ] The only other worry I would have is just test coverage of this change. I suspect very few developers use HIGHMEM. And I know the various test robots don't tend to test 32-bit either. But apart from that question about naming (and perhaps replacing kmap() entirely), I very much like it. Linus