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