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 F2668C77B73 for ; Wed, 24 May 2023 10:23:41 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Dnh6B5SuMO2VmfbipevgBPthxgrcPh46hNuHoeWNiHQ=; b=zo371PLrwuTIb/ wnsvUlzN14WkFSoUKmN3YkC9560Koj6ViNpvfUJdlTITxmIrUXg6fpLVNbpRjds4TCBS04CCof6Hv I5O/KKEExMFAaacLsaJqCbEo8SzPgFiKHzmVgEnECBvMkQ/6n/pu84F0oumrmVfOYvUS5pzo37o8W 13j0iJWdx7PdO5REiiywo40ghK60RNq64ARxtlmHSyj9IpCbsTqV95mPdbtuIXRg+YLzTKKwLuHVD G65fVCsvBoXvZCxDVP5oTbUIHfYV+NbR96RXXnjYAk/miBImaTO/BsAcsK7+PMyCeV+KsIEUivoTN hlOlwOP9mVvWl+nBOwrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1le9-00D5OF-2J; Wed, 24 May 2023 10:23:09 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1le6-00D5NK-2o for linux-arm-kernel@lists.infradead.org; Wed, 24 May 2023 10:23:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KT3gEjzKYdflmxBfXJo8ODMA1GrmOQJl0LApTtsZvIc=; b=VOKi9va/fmReWbaglO2iX1mt0s A2YbqfFFUM8Zf7tDmhMXor3tI5hPjOZliaMVMGx9CFkcFeqgqRrQpIG/tZBnreJppJ7GfhCiiroQk 3vuTEHXYZZBWqspO57aflSr/0twchyllXLNL0SsOZ4RSJ+l/UyWaot50AapplcYkuxn10gpuMmoSU crzJ0q/SRnw0tNiEnzHXIllZ581IUpOfBuH2lSA1FcbyrGkl4H6ugOzboPMosZrj9n5b62MHBT9K0 nZIAt9j+Nck8hpsDJTX07eM5lsx04bC24lOogMLNpczJK2sgqfPADJzfNTddRK/AjZB+kp44rf6n+ lOG2ctlQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:48344) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q1le4-00028X-3f; Wed, 24 May 2023 11:23:04 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q1le3-0001Xb-B5; Wed, 24 May 2023 11:23:03 +0100 Date: Wed, 24 May 2023 11:23:03 +0100 From: "Russell King (Oracle)" To: Robin Murphy Cc: Thomas Gleixner , linux-arm-kernel@lists.infradead.org, John Ogness , Arnd Bergmann Subject: Re: [PATCH] ARM: tlb: Prevent flushing insane large ranges one by one Message-ID: References: <87pm6qm5wo.ffs@tglx> <14ca0866-cdf1-736c-409b-7318bdfba71f@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <14ca0866-cdf1-736c-409b-7318bdfba71f@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230524_032306_907031_23D79DE3 X-CRM114-Status: GOOD ( 32.46 ) 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 24, 2023 at 11:18:12AM +0100, Robin Murphy wrote: > On 2023-05-24 10:32, Thomas Gleixner wrote: > > vmalloc uses lazy TLB flushes for unmapped ranges to avoid excessive TLB > > flushing on every unmap. The lazy flushing coalesces unmapped ranges and > > invokes flush_tlb_kernel_range() with the combined range. > > > > The coalescing can result in ranges which spawn the full vmalloc address > > range. In the case of flushing an executable mapping in the module address > > space this range is extended to also flush the direct map alias. > > > > flush_tlb_kernel_range() then walks insane large ranges, the worst case > > observed was ~1.5GB. > > > > The range is flushed page by page, which takes several milliseconds to > > complete in the worst case and obviously affects all processes in the > > system. In the worst case observed this causes the runtime of a realtime > > task on an isolated CPU to be almost doubled over the normal worst > > case, which makes it miss the deadline. > > > > Cure this by sanity checking the range against a threshold and fall back to > > tlb_flush_all() when the range is too large. > > > > The default threshold is 32 pages, but for CPUs with CP15 this is evaluated > > at boot time via read_cpuid(CPUID_TLBTYPE) and set to the half of the TLB > > size. > > > > The vmalloc range coalescing could be improved to provide a list or > > array of ranges to flush, which allows to avoid overbroad flushing, but > > that's a major surgery and does not solve the problem of actual > > justified large range flushes which can happen due to the lazy flush > > mechanics in vmalloc. The lazy flush results in batching which is biased > > towards large range flushes by design. > > > > Fixes: db64fe02258f ("mm: rewrite vmap layer") > > Reported-by: John Ogness > > Debugged-by: John Ogness > > Signed-off-by: Thomas Gleixner > > Tested-by: John Ogness > > Link: https://lore.kernel.org/all/87a5y5a6kj.ffs@tglx > > --- > > arch/arm/include/asm/cputype.h | 5 +++++ > > arch/arm/include/asm/tlbflush.h | 2 ++ > > arch/arm/kernel/setup.c | 10 ++++++++++ > > arch/arm/kernel/smp_tlb.c | 4 ++++ > > 4 files changed, 21 insertions(+) > > > > --- a/arch/arm/include/asm/cputype.h > > +++ b/arch/arm/include/asm/cputype.h > > @@ -196,6 +196,11 @@ static inline unsigned int __attribute_c > > return read_cpuid(CPUID_MPUIR); > > } > > +static inline unsigned int __attribute_const__ read_cpuid_tlbsize(void) > > +{ > > + return 64 << ((read_cpuid(CPUID_TLBTYPE) >> 1) & 0x03); > > +} > > This appears to be specific to Cortex-A9 - these bits are > implementation-defined, and it looks like on on most other Arm Ltd. CPUs > they have no meaning at all, e.g.[1][2][3], but they could still hold some > wildly unrelated value on other implementations. That sucks. I guess we'll need to decode the main CPU ID register and have a table, except for Cortex-A9 where we can read the TLB size. If that's not going to work either, then the MM layer needs to get fixed not to be so utterly stupid to request a TLB flush over an insanely large range - or people will just have to put up with latency sucking on 32-bit ARM platforms. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel