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 8CDE4C77B7F for ; Tue, 16 May 2023 09:13:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1124F900006; Tue, 16 May 2023 05:13:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C29E900002; Tue, 16 May 2023 05:13:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECBA4900006; Tue, 16 May 2023 05:13:49 -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 DAB3F900002 for ; Tue, 16 May 2023 05:13:49 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A9433140108 for ; Tue, 16 May 2023 09:13:49 +0000 (UTC) X-FDA: 80795555778.01.EF9F7D9 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf20.hostedemail.com (Postfix) with ESMTP id F295B1C000F for ; Tue, 16 May 2023 09:13:47 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="SeVG0/P7"; dkim=pass header.d=linutronix.de header.s=2020e header.b=WM4AlFTr; spf=pass (imf20.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684228428; h=from:from: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=mE4+4BNXwYdvrVmsT7mDx3bW5dhj59Ive2ha7U118VM=; b=LZVCmoj069tpfMMFOaDUR5GDrmalUfwYObxo3AXImepxJDoTWBFu9O9xOig5srNJzqTd+x gCcuBURe8EyjwkV6BBkUoQ2zQ190DNGrbciJ2p/VNlLE+jx+DJvHk1pASPYPxBGzGyjU4E /494iw0hfgyRrBhQB4hI9P07P9pFmu8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684228428; a=rsa-sha256; cv=none; b=SpD7CmKT+XK7qdW7uW7Oz0v2WrSjImXXll/cKRPlgjLKPZS1zUnN38KFMYD4R8HjRusJjo EtfH6z1HGg5K4abHOeQ87w3aANmLnX4ibp7kubjkpMhHPzXNCAwnlq3PdVif6HvfB7KcEA eF3CAcNCkK3IMtbY6WnVC9ZBPbt4c8c= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="SeVG0/P7"; dkim=pass header.d=linutronix.de header.s=2020e header.b=WM4AlFTr; spf=pass (imf20.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684228426; 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=mE4+4BNXwYdvrVmsT7mDx3bW5dhj59Ive2ha7U118VM=; b=SeVG0/P7t/PfRxhjp4uFKytneQ/2Qnjli4OS1U31T37Ts1ErxZhbiFK4uhSycTibp8UA1y kpqDUk0uJ75WgbkVg+a2/gaEP9OAz65wDI39CvCMIr1rm8eJG9qUXrmtdWF/HCntEE4O/a RitgBXEean3N+OrSXCfkXIpf+tRfjCSCuZSLbYecvBQyOeWwpqUuslw0Wosj9L0goJaAUP qfEOYTS5pOzY0CFCLE9X6SO/hEIfsmUIdhgVlynGt8rinDDkmzGtXdVJkkikbG6YL/Egk6 UQUHLplZAUGkQgZ4ON33+CofR0aiKpLMUJxyDfIo4Z7u3G/8jKf0uvsM3ZwM0g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684228426; 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=mE4+4BNXwYdvrVmsT7mDx3bW5dhj59Ive2ha7U118VM=; b=WM4AlFTrB54vAi+kSbTE1QEEhGqnRb+7gbcuDOadfisFwQmXw9mCKL49Y6TWBSTaB6Grq2 DSd0zbHbClTVEwDw== To: "Russell King (Oracle)" , Baoquan He Cc: 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 In-Reply-To: References: <87a5y5a6kj.ffs@tglx> <87o7mk93tc.ffs@tglx> Date: Tue, 16 May 2023 11:13:45 +0200 Message-ID: <871qjg8wqe.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: 3ptck3zgg8ad9f9tnp7fki1g7dgpghzm X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F295B1C000F X-Rspam-User: X-HE-Tag: 1684228427-490525 X-HE-Meta: U2FsdGVkX1+c3X8my3Tu7fgf2ucwO4UuMMAmzOC7WXEyhsWrK5X1Lieek195e8qOoVrsrwdQFV2YD13tJHfi60ePNAY/bivaHOmDXBiA/n8ri8idPBvmvsgTC0zYYubG4HGFD+gk4JvBF1aFP4tAeXPP7H+1OXwzUN2ZslfPiuR7Fb5IGVWN+FJdN7FRv5FemXEWbLLAbVhKPl/w5h8EZdgIAlL/g1WJdTWsEa21Vekb5HEi0czeaKuPgkzYmhDyn3vhLeDQmcKjE6piCS9VSxY2mChp/WQ+X2B3qX65y6eFzcn7J2SUlJuakr15ygjOqeowk6ShShj8wXaJs8SNJzh9sZBwNppnGw4bSDbFAkJUnGhnZ8spyt65l7EZYkmNG6tX0ERgYLJmke42HxDANUuwz6KX+9JmnJQMN0wLlLiXAgv3aF6uJR+9T21L2fYvoFKHvEWLXXzSEMCAihdIumczsAKIBPcVJ8N4iaEA0hT5kh8ZcMo/26NT4lWIhASkmZz5LJuN/Wt+gpP/JHivedPocgL4mt2Bihm0RoMyUQsbyMwHqAsKh+zXYtsvfwJO0PmnqcBvhGV/JvXeb9Bj5ac5frSmbBE3ZnUwTJmFNzFN2OLFFd9Rtb9iDl6YoVUYqwUci5ZQyAaE0CGkzeeqT0Bg/t8U6QgzU3DCqtgHVDKMJ7195FvmKaQR5Jny6n+1d+XhgX3TgnUdhm9J8lo8hARkkmU5hBB3CTdm4kvcwCXlQ6yXV9+vMt1bsqzrSbAya6Rq5y8thAtDPJWQQPV8tK3CIzD8yOd/JnBsEW6AwbFsqCPj9MLsvgwA7jvJrt49fxjyw56gPT9H/zVyRSXWAn0mCvEai0drEHbUZWsafUaevTL7LgZ4IJmo1rVglTy79exLbeKk3e9bClGvDSd3FUoJoDsya4ZPRMr41o48Z+cVknD1NQqy0tmU2wxYXsCq3yiUEuQ0IxGGUK+X+ye RABUM0rG LYiA7NUjUZinoWBKwrKBQLAkgruNwU0Y6Un8vt2TaFgqBGFk= 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 09:45, Russell King wrote: > On Tue, May 16, 2023 at 04:07:17PM +0800, Baoquan He wrote: >> 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. It does not matter whether it's rare or not. The scenario which made us look is that CPU0 is housekeeping and CPU1 is isolated for RT. Now CPU0 does that flush nonsense and the RT workload on CPU1 suffers because the compute time is suddenly factor 2-3 larger, IOW, it misses the deadline. That means a one off event is already a problem. Thanks, tglx