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 B290CC35257 for ; Mon, 21 Sep 2020 19:28:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7280D20757 for ; Mon, 21 Sep 2020 19:28:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="HxqY5bgm"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="K+USVXwN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728103AbgIUT2B (ORCPT ); Mon, 21 Sep 2020 15:28:01 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:53520 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbgIUT2B (ORCPT ); Mon, 21 Sep 2020 15:28:01 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600716477; 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=NioanSWzd78GxCsWYULMNfEWngL7gbmu+5wZKJGKPtI=; b=HxqY5bgmLL1k0f3vQQxKwcT5ry3L+n9eWbaa33JpgBbIQhQKyF5a3ij8mv6CpgblAufPcl /NboBbVSLMzTqFGT0TjywuRmfs5bzTYeJmHXAxo0CVpHx+Vc+AcZ01mg2TfMdqQ2YBFUr0 T0biE/Xj6CpNppEeI1NN60+4LlXdME7cpu0hU+LkVE2Ap5bde7RRe7hWtZJQkXhhKWa8iV 9G4YL/t1/f3WBUyUCaKsXVKPluf5ho1Tri7IYKrkld4lHHpsIFR2kj//UAVDisud0CvF9E Y+o/6lfteq1OBhGqZU5+eNzFDwvEzWDxVn5dG5jL6fLqKaz4jlZKqLWOR91+lA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600716477; 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=NioanSWzd78GxCsWYULMNfEWngL7gbmu+5wZKJGKPtI=; b=K+USVXwNO19/CLwxF7hr/zQjzSe76M0Cqo3jC86XX3is24rhnFQjsCVAxPA8kns3xbx5QG vlmVOJebsjPrOqAg== To: Linus Torvalds 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 Subject: Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends In-Reply-To: References: <20200919091751.011116649@linutronix.de> <87mu1lc5mp.fsf@nanos.tec.linutronix.de> <87k0wode9a.fsf@nanos.tec.linutronix.de> <87eemwcpnq.fsf@nanos.tec.linutronix.de> <87a6xjd1dw.fsf@nanos.tec.linutronix.de> Date: Mon, 21 Sep 2020 21:27:57 +0200 Message-ID: <87sgbbaq0y.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote: > On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: >> >> If a task is migrated to a different CPU then the mapping address will >> change which will explode in colourful ways. > > Right you are. > > Maybe we really *could* call this new kmap functionality something > like "kmap_percpu()" (or maybe "local" is good enough), and make it > act like your RT code does for spinlocks - not disable preemption, but > only disabling CPU migration. I"m all for it, but the scheduler people have opinions :) > That would probably be good enough for a lot of users that don't want > to expose excessive latencies, but where it's really not a huge deal > to say "stick to this CPU for a short while". > > The crypto code certainly sounds like one such case. I looked at a lot of the kmap_atomic() places and quite some of them only require migration to be disabled to keep the temporary map stable. Quite some code could be simplified significantly especially those places which need to do copy_from/to_user inside these sections. Graphics is the main example here as Daniel pointed out. Alternatively this could of course be solved with per CPU page tables which will come around some day anyway I fear. Thanks, tglx