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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 23BF2C77B7F for ; Fri, 19 May 2023 11:50:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=30c391vFA/J4dMLCz4msI/naPLGC9ukl8LWPKWPqGCE=; b=QkWK9r2d69FPWI gUCzxmO+eIzZaJhwZ4eaBsmB8e9l0NSHwIqwC3LjTqAWdCYSnpKiwoiOkK2E4/HvGd7wXatAwSyda o7k83BMpCwhIsm1jKTXZdfQPl/rmis9SPbrO7i+afebHRPn7ZopzDHbJdZUGw0C9aU+5cRxURlTIE 2dsnmRy8SdaQgdVFLYcsHBrrwQpJY9BMKSm0K2xyrjHrHT3/JQOWQGfsAzChvmr8WwRuHdOpvazjm GQ1ciHVw/LwYpO2b13Oo6PVH5qiNZ+5bY6Xubk8a9akalwa9D0VTLOh8NgioubUt5Tjv4XQyqlhLh UkUHHy+Zs8j6jkh5revg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzycP-00G9S9-2n; Fri, 19 May 2023 11:49:57 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzycM-00G9RH-27 for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 11:49:56 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684496993; 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=/gl+WveyiZlpb6+4DFS5GDG6sgAY+Qor5hURVGk6SKg=; b=anpFlH/WpylVc/rgeooyvcHPnwqcj1VUuupdqaoyXlqLndX1GU4M0CSKZQ9gSctQ/D+YUF K6V4lMts2fL4sG9DiH8FiSoxPsAvhQaQB6glQAb82Osh6sPkCzICfzVLDAugKriK715ldF Z6EVYdzpuEk1m1DvlmWnVyhauMumI1EPZpmlnPw8fZyFGwVDHdG65U+2NkQy5NZJ8Q64Fo ICBQjSKmB3wwZn+jqACUD5LZo7LCCfFZa5FfjgB7uMLR4hQL2qiqFb0IwyLxYkqc7Trm8L WiPU5xiLCiLR7IsTA5RRj6KfPqbT9xwNqruFzbrOt81wduIKBPQO5PX+/6i0mA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684496993; 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=/gl+WveyiZlpb6+4DFS5GDG6sgAY+Qor5hURVGk6SKg=; b=HIGP5RUOjbfysdEbXIH1W4NNpdH8MDtbeFJCMpI+clLeLi9dUH5E6XkMzFsgskcfbbU1W/ K/u8eVmyNowmVFDg== To: Nadav Amit Cc: Uladzislau Rezki , "Russell King (Oracle)" , Andrew Morton , linux-mm , Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges In-Reply-To: References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> <7ED917BC-420F-47D4-8956-8984205A75F0@gmail.com> <87bkik6pin.ffs@tglx> <87353v7qms.ffs@tglx> <87ttwb5jx3.ffs@tglx> Date: Fri, 19 May 2023 13:49:52 +0200 Message-ID: <87353s5yn3.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_044954_832833_B76845A8 X-CRM114-Status: GOOD ( 13.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 17 2023 at 15:57, Nadav Amit wrote: >> On May 17, 2023, at 3:31 AM, Thomas Gleixner wrote: >> Maybe ARM[64] could do this smarter, but that would require to rewrite a >> lot of code I assume. > > What you say makes sense - and I actually see that flush_tlb_page_nosync() > needs a memory barrier. > > I just encountered recent patches that did the flushing on ARM in an > async manner as I described. That is the reason I assumed it is more efficient. > > https://lore.kernel.org/linux-mm/20230410134352.4519-3-yangyicong@huawei.com/ This operates on a mm and is related to batched removal of user space mappings. That could be done for vmalloc too, but the life time tracking, i.e. ensuring that a nosync flush has seen the final barrier which ensures that the mapping is not longer visible might be slightly more tricky. Especially with the full x86 centric code there. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel