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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D00B6C7EE24 for ; Tue, 16 May 2023 08:45:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64B00280001; Tue, 16 May 2023 04:45:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FD86900002; Tue, 16 May 2023 04:45:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C406280001; Tue, 16 May 2023 04:45:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3E23E900002 for ; Tue, 16 May 2023 04:45:18 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0C1D3A019C for ; Tue, 16 May 2023 08:45:18 +0000 (UTC) X-FDA: 80795483916.04.55C7597 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf09.hostedemail.com (Postfix) with ESMTP id 07A4914000A for ; Tue, 16 May 2023 08:45:15 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b="IaVfY1l/"; spf=none (imf09.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684226716; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9JGvtPYX7dIVVK6xaFykrwaQ9dd2AjCgm6XmSZLNI7c=; b=E26Xh3VBM40HWP9NC7/lzeHIMeMVA08HkJUlpzI84GwGGE7wVfBBk6VAUf8Ynn5O3udsdC wuZoZVGLNOFkB6faoircSBs4alENZKTNO2/Xba3z+DKIIp2b7WNpTwYjish5BWr9wgP5rI qopHNrVfUHtl8gkEe4Vs+yTWniraXWs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684226716; a=rsa-sha256; cv=none; b=15b0afGfPm9hk7alVZ/nhm0rKM57n3ek9mtonjzi1+vrneysOQsVHNDGOywCG6uttyPft+ hkWehwwmCur3KsV7jsms4lm07E0uA4fi79Kaeh7S2gJZML2gEmHcuMVHlJ1V71MXGqWS6L eB5vkdhsgidF+TXHsYERxfB4I3GQZdI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b="IaVfY1l/"; spf=none (imf09.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk 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=9JGvtPYX7dIVVK6xaFykrwaQ9dd2AjCgm6XmSZLNI7c=; b=IaVfY1l/lKxu3ag81OENShxcF6 I1sbAy/X7tF7FhfPGr36AM2zTu+6+pgpKxm7mGOp6aXgGDEHMdzQeq/isETgSfIHtqKlFF+izD9kP QVj+DCaPB6uAg6bjDZjfbuId0NMwyasmzT0Uvvs6mx+ifmlEE6B4ihYx2vN85G+aWoIZJIJpB0+xY EpfaIN9jBED/47W6jZSe+rt0svQG50BkOdtX+AclXzfKknCS3f/Gfnm6O/euThUrf197M9Zft9Zxg r0g+nhIDgZpnEQNAWc+7pyDzyvccTZXRb1puUblzo8sYjmyOMj3c5UTqpPFrUjNSCXoTgbZNb9MDp vf0+RD4Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:41390) 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 1pyqIx-0005OL-A4; Tue, 16 May 2023 09:45:11 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pyqIu-0000fR-Cq; Tue, 16 May 2023 09:45:08 +0100 Date: Tue, 16 May 2023 09:45:08 +0100 From: "Russell King (Oracle)" To: Baoquan He Cc: Thomas Gleixner , Uladzislau Rezki , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier Subject: Re: Excessive TLB flush ranges Message-ID: References: <87a5y5a6kj.ffs@tglx> <87o7mk93tc.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: domz5k3obota1uhx8wzxcdwcngf5w3xd X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 07A4914000A X-HE-Tag: 1684226715-377692 X-HE-Meta: U2FsdGVkX18S/YgRY45wTtMCkChgH1dKFbvWDE9clz6Hsnz5gS7to5EvtaOTDSQzN9320q+PyNTgI6pWpY/qfQ3VAe6U/C8I3+ZNdupYKcWKN/rlGlRYYuVzfBA3r8lZ1hrayECgqoO19IdA/oOECXkMjDd2ukqkKE0hrIDj6ssIvPMcHuPvVE9glM8Y+EHd5xjgkx3ihlPIW+vNWT+XYmMdCgHCm/bCS7hKeGHxONVo8FG4qEMU/O8ovo55TUOTqNkXNoU6V7S33xnM6aIUA5glI2nqTxS8qDB2DgtjQdA1axBOlEZNZ/WwQBvZP6SfjgpGpkVPr+qMUxYq+X/pvpnUYgz5TwzP+hukfaTUWfIykAyayUvy+Gw2CIzQ3a5PxXhPbhTGoOdGlmCAgVQRvusRRf1xu4sIa/Vug2+UdkFn1BfTVH2YBdvgPx83taFKvTxPczhiNRAW/+o1B8P4KsPYQhc/E2OE3gEto3/3ONFDqiBDmXbbUNHWGYNPZ8O0KF8WA9+8hNkirODXBKsEISS6sVy6L1upRwDhZtGDMx4IDQAm8UCOl6KUvsETRqoeJXO6ugyPBHlwgCO5QApxKOEdctLA9y9BmfEFsaUix359TMfqpgD0AG33CMpCobfqyFSHiKnexz7W4q2trTTqYaWLIBhF0VTmoNt9p7WO0cRpNLHMbn+QDFAWOE6yFJ2xM0dhCBBWx3mGdDvZBV1nt2AT5tSoIYZJ59CMwWKIfwn6OhLC8XvkM/ZkHsR1eWhoWiY/BAQGnKEDL+aXYd9aTTogtF00k3lbV7uM3GPE0SwtJ4uuI6jNPxVgYIFogLFAscODxd7BhADmYo3Bs58EjPd8lfEwIsGn7vYAdPgT5I1LIli49pvQm7TubS5OIgIU3WDPlwWX+IJp8tZjt8iB6H/kDMbIEn1JYa5kd47q8TdPhQ9I/BmMB5ekqMCbD1I+L79mjCxTTL3Co7fAI/g 7DNO4H9W Q33GCiAKXu+fhMY1/xSMyvWk6aIc2XP33CsI4wxrV82/g6Nlvy/XC1krcpmjMQDxL5EGUI13vPYUSJ0z8P0WQSqj11+IuR5yEVVwcJ+sZbH3QrDYK+qPxFOLnwksD6WxtbqeQDQOnx7E8sgGBRN1Rbdts5Mw5pMVZ3GotbWPCIqHUFh7n+rdv4OaZv6jf6ylvXBRHK5Ule7GqNHsxPKDg9U2UBo2xp0UhVyTiTGXwrOmIZjBGrGsrkeKIx9Nb6YRThrHQMzeC8QzxTXMXQnD2hguEfHOMsr09xg8bn9Nrjn7GWYYIjj1CYco3ZEG5CluPVA3rMOWjq2WNljc0j33+W/f2NgD795N954MfUnJBNgK6Yt38jQL7MMxiLZ2+pSkElwLpZR0vzKgzVao3crSvAKDQgMP8TnXLQv7iLAS1paeYjN8uJFLA8YrjJ/XM7lrNkukUeTuLKCY/SGhjJ0YIpozrJk7iuO1BOyWvtdvx8/Qq40mOgs+AJYLEiEBnQ9RrWGYhk1HPp6T5niOsnYJ6/90j5oLvy0zLH6mY8om/VwM4AV8ufap9Aw+kSA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 16, 2023 at 04:07:17PM +0800, Baoquan He wrote: > On 05/16/23 at 08:40am, Thomas Gleixner wrote: > > On Tue, May 16 2023 at 10:26, Baoquan He wrote: > > > On 05/15/23 at 08:17pm, Uladzislau Rezki wrote: > > >> For systems which lack a full TLB flush and to flush a long range is > > >> a problem(it takes time), probably we can flush VA one by one. Because > > >> currently we calculate a flush range [min:max] and that range includes > > >> the space that might not be mapped at all. Like below: > > > > > > It's fine if we only calculate a flush range of [min:max] with VA. In > > > vm_reset_perms(), it calculates the flush range with the impacted direct > > > mapping range, then merge it with VA's range. That looks really strange > > > and surprising. If the vm->pages[] are got from a lower part of physical > > > memory, the final merged flush will span tremendous range. Wondering why > > > we need merge the direct map range with VA range, then do flush. Not > > > sure if I misunderstand it. > > > > So what happens on this BPF teardown is: > > > > The vfree(8k) ends up flushing 3 entries. The actual vmalloc part (2) and > > one extra which is in the direct map. I haven't verified that yet, but I > > assume it's the alias of one of the vmalloc'ed pages. > > It looks like the reason. As Uladzislau pointed out, ARCH-es may > have full TLB flush, so won't get trouble from the merged flush > in the calculated [min:max] way, e.g arm64 and x86's flush_tlb_kernel_range(). > However, arm32 seems lacking the ability of full TLB flash. If agreed, I > can make a draft patch to do the flush for direct map and VA seperately, > see if it works. The question IMHO is not so much whether there's a full-TLB flush available, but whether it is appropriate to use it. If we're only wanting to flush a small number of TLB entries but over a sparse range (which seems to be Thomas' situation), does it make any sense to flush all TLB entries? I don't think it does, but it depends how often this occurs. If we're doing it on a regular basis because of some workload, then that workload suffers. If it's a rare event then maybe that's okay to do. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!