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 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 CB8BDC56201 for ; Fri, 30 Oct 2020 09:39:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F7422076E for ; Fri, 30 Oct 2020 09:39:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Ijhg5aiO"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="irizuuQY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726144AbgJ3JjO (ORCPT ); Fri, 30 Oct 2020 05:39:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725876AbgJ3JjO (ORCPT ); Fri, 30 Oct 2020 05:39:14 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1B16C0613CF; Fri, 30 Oct 2020 02:39:13 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1604050752; 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=EWXvaZJ4n33nUPpVqCcdjcDSYO5R/m7YAVCZo4qnz/w=; b=Ijhg5aiOMjBRx5rip6SYYGDFE2m3YLjbUBNKk+3NGBAB4R2XV1b2EqqlklIKhs9UUNQWQk z/BOQowWvycG+wd7WP6RDL8dKFwe1UJ0MqD2fe1iCRjFdXzP4PF0WPpHnySjM4mSn8TEDZ +rgRtwXuNFbgN3K9VuqJ5Qlvu3gg80bUbRb6nNMR+/JhtI3yWewHHZND9q4GfI+B5nak5E Txo5XRuNfIVvWuFUn8S5xduuQjkyrzj/pylK3pN+rsWG4as9auyvNfq1rB+V6+q9oD9RYg uWDVVgapgL3toLNiaXgwAR/Xo8x02IWniqNGp0tW1Ptti3gNq/7xKk1DGerynA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1604050752; 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=EWXvaZJ4n33nUPpVqCcdjcDSYO5R/m7YAVCZo4qnz/w=; b=irizuuQYfZdKA41k2RTCVBIm8nOzrSmQrzmbTW+9NWSzofxsL3XYrjHU85eqQdOWzHFOzN nZb9SEwnLnGs5ZBQ== 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 Subject: Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends In-Reply-To: <87pn50ob0s.fsf@nanos.tec.linutronix.de> References: <20201029221806.189523375@linutronix.de> <87pn50ob0s.fsf@nanos.tec.linutronix.de> Date: Fri, 30 Oct 2020 10:39:11 +0100 Message-ID: <87blgknjcw.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org 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