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 B692DC77B75 for ; Fri, 19 May 2023 13:50:08 +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=9eE2vKKvth7utV++4abhY5teuEc1ZXlpkdPfBdAPrs4=; b=1btwBJVTVjKf7S un7THsdWIbekDPZ1/1PJB7zDeK2MRYaySYNwBjTwpyUyUsZuthUxVXGT2GlNK7Fyf1Ui9OKMWurAd iWSPPlQXotL6s0h2p5G2ZbQj2Luaf9u48QGhHwtD3ooQvQNwihNTTC542Bkye6tLarJ8+IfffcCJU yuBrPoN22dqGdHxNGJkSiyUF9NwOfGuF14rZX8nmlWr+VbSq5YL8zQdTq4d5K6ij/KKVVY8QxKyG7 fgTzHh7NWERRDoL1x+Oi1cqrhtu9Krtur+akTJZ7kF9ShJv29r83xWKpHPFhFYEu/bzWCmvleEeNv OSXQ9SV11ZTDQBBWgn4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q00UJ-00GQ5i-12; Fri, 19 May 2023 13:49:43 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q00UH-00GQ4G-0b for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 13:49:42 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684504175; 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=7YB/wKT/1bpvMrLNerVNPlSTQb06G6thmKxqchw5MIs=; b=RLTvUPb+0WIGsMGKDHv5enz4fluw7kxP1wuSc+UBfCBgI73xKCuj9mm5xvYHhnBDUKdYjh aHqdLYN6PL0xdX2al9zlPfsPXTPhncLhECp+xsn+2P319xImnVgG8qLzHBq2OHByt4bIFj ynfwLhJfB3xyYlyAKmPCSILv8XG2FYjQw0r5kD2uBq8sC/hSUI0U0Cg4O9Kt6SZM6AyJfN xlRBfZnkzKNB1RDc3DI9JjTDOqe0T4H2yFPfPrCvWr3Z7xrRkdzl1WGV9C8e0487DR20Fh eUAlUFb3pUf2UfIB4/SmGUz2jRC2K8579T5m0OkHRXqo5HpOg/DnwEHkcwPg5g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684504175; 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=7YB/wKT/1bpvMrLNerVNPlSTQb06G6thmKxqchw5MIs=; b=3GGH4vCFFYjxEq+NVk+8a8qjxhINNqwuu632bnXERmLiv6Ttmkh3BcM1FJZeo5ZpTx0IkS 5e5XnyUzQdSpimCg== To: "Russell King (Oracle)" Cc: Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org, Nadav Amit Subject: Re: Excessive TLB flush ranges In-Reply-To: <874joc8x7d.ffs@tglx> References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87ilcs8zab.ffs@tglx> <87fs7w8z6y.ffs@tglx> <874joc8x7d.ffs@tglx> Date: Fri, 19 May 2023 15:49:35 +0200 Message-ID: <87wn144ej4.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_064941_367319_41B3E551 X-CRM114-Status: GOOD ( 11.13 ) 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 Tue, May 16 2023 at 11:03, Thomas Gleixner wrote: > On Tue, May 16 2023 at 09:27, Russell King wrote: >> implementation, there is flush_tlb_kernel_page() though, which I >> think is what you're referring to above. On ARM32, that will issue >> one IPI each time it's called, and possibly another IPI for the >> Cortex-A15 erratum. >> >> Given that, flush_tlb_kernel_range() is still going to be more >> efficient on ARM32 when tlb_ops_need_broadcast() is true than doing >> it page by page. > > Something like the untested below? The list based individual flush wins over a tlb_flush_all() in that particular scenario. It's almost in the noise while the TLB flush all has an impact of ~1% on the other CPUs computation runtime. That's just a quick check w/o deeper analysis, but that clearly shows that there is potential. Whether the list or as Nadav suggested some other storage turns out to be also benefitial for IPI based flushing is still subject to investigation. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel