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 99E98C77B7C for ; Wed, 24 May 2023 15:52:32 +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=e5vaKx4aq4uvItrhkIMcXHX1CKggZmx76x1iHavoTAM=; b=w7Zxxk74PcrbkN eU4iNTmMK1qvYdFnUt+5Pp9avXUxye1FecSvkMbidIOWgKEIx7aTko6HnzKh6LsmRHb0I3riacr+9 xA5PAa+Ig+BYGeUAICkUmyB04vC4Nh0F6Jxph+NEZRP3m32WewsTt9oOKVFE1c5zGd5ii66iAnQ6s Gk9p4CsMrlo2DfsH8n2rRVepivk6sQPWtDAvtWjS6SWai8AXUDVMWw1iUK0viMNewOz1aossdE/Xp gl6GE3aLwOEsvyE9SCfiaNP97COJma+QSioH7sAXzkLNScdhe59tPmjMitpgCeY6cr13ogUVeLeCb eyYyAd0zliJVSVfF4ejQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1qmV-00DuBv-10; Wed, 24 May 2023 15:52:07 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1qmL-00Du8i-2R for linux-arm-kernel@lists.infradead.org; Wed, 24 May 2023 15:51:59 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684943516; 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=B40+4ZOgiHNBXsAuzBgdhMmTqas2VCODbdmYFmxbyV4=; b=LJgLkA3auA9ayRMh6sdRIzfJLLhuGdKkuRMkQ9rjxV0OrG/jMnOtZVok1s+k2U8D+vVN/i PWjyT0nHweJYmNBjRV8OYUmFlaXsiHyS8c9tSvg4n4hzc0lwXnEez7SDjlc2cevEAiVBJ8 nckF+DotevjoD1qx+uCjwnBQeyPefaQRO9k/f8NeIxepx3CkUt8iNkV4wca7BzLcL5bQD/ 4gtcjw6yvNeBXwhsKMKxdzn8zHNBsIQ4fs9u/B7jFJiBUMGEcj7X3Gnnu7CQoAz58gVvSQ T+F0MMffOp6VjOv6JYGhFrnSR8iQdiyPf3HFgHboDUpUTyfWLbvJZQC9ywaPbg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684943516; 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=B40+4ZOgiHNBXsAuzBgdhMmTqas2VCODbdmYFmxbyV4=; b=M0I+T2gkisJ4ZEkKvtgmrTRSL44UUcqkCVgdNOzCm6S7+tT9HufkQg/tjz8JFnf5wfBJay H29UAqV6AyOcuDCA== To: "Russell King (Oracle)" , Robin Murphy Cc: linux-arm-kernel@lists.infradead.org, John Ogness , Arnd Bergmann Subject: Re: [PATCH] ARM: tlb: Prevent flushing insane large ranges one by one In-Reply-To: References: <87pm6qm5wo.ffs@tglx> <14ca0866-cdf1-736c-409b-7318bdfba71f@arm.com> Date: Wed, 24 May 2023 17:51:55 +0200 Message-ID: <871qj5n2w4.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230524_085157_939079_592FEC82 X-CRM114-Status: GOOD ( 21.48 ) 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:23, Russell King wrote: > On Wed, May 24, 2023 at 11:18:12AM +0100, Robin Murphy wrote: >> > +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. Bah. > 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. The problem is that there are legitimate cases for large ranges. Even if we can provide a list or an array of ranges then due to the batching in the vmap layer it can end up with a large number of pages to flush. There is an obviously CPU specific crossover point where N * t(single) > t(all) + t(refill) That needs some perf analysis, but I'd be truly surprised if $N would be large. On x86 the crossover point is around 32 pages. Lets just assume 32 pages for that A9 too. That's 128k, which is not an unreasonable size for large buffers. Though its way under the batching threshold of the vmalloc code, which scales logarithmicaly with the number of online cpus: fls(num_online_cpus()) * (32UL * 1024 * 1024); That's 64M, i.e. 16k pages, for 2 CPUs... The reasoning there is that a single flush all is in sum way cheaper than 16k individual flushes right at the point of each *free() operation. Where the vmalloc layer can be less silly, is for the immediate flush case which only flushes 3 pages, but that wont show up yesterday. For now (and eventual backporting) the occasional flush all is definitely a better choice than the current situation. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel