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 D349EC77B7F for ; Tue, 16 May 2023 09:14:10 +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=SsHCIp2Q1oterxxbTYcMXiDORdu0AZ24wQL4E/6kZf4=; b=XR1HUGmQ7VJRnh KDgGw+7dWJF6xLTDypyom/Ggli9x9JJ4d0wVv2Vn20ZZozZ2WypI7pTFNQgLtqTJsN6z2Wk5/0i0H vUUUifR2oXvoVOpFKd15zMcdlzjXDHScWBiEaE7nuy0ieVCS3uXdTpl+r17/DNvkOqS0fgbpPQdQb gzw23YnRiQSF7mPpWvaXlDJcmoi3qsoNFlgzqXY1I/ucEOZV/fqgSjctuY007PHBXoNarRNBzDr3E /T3sMcwLsknDpIEv45dfNS7XZLW79xKHGcLqFIP5CdBfTDs2gDTrxKRTDvUbm9m45DYd2CGEsznMt KHlgNuZxEcY8LeLFdlZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyqkf-0050fz-1k; Tue, 16 May 2023 09:13:49 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyqkd-0050f0-1g for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 09:13:48 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_021347_698336_19A6E719 X-CRM114-Status: GOOD ( 15.34 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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