From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 426E77D90D for ; Tue, 9 Jul 2019 01:02:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725935AbfGIBCa (ORCPT ); Mon, 8 Jul 2019 21:02:30 -0400 Received: from edison.jonmasters.org ([173.255.233.168]:59276 "EHLO edison.jonmasters.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbfGIBCa (ORCPT ); Mon, 8 Jul 2019 21:02:30 -0400 X-Greylist: delayed 2192 seconds by postgrey-1.27 at vger.kernel.org; Mon, 08 Jul 2019 21:02:30 EDT Received: from boston.jonmasters.org ([50.195.43.97] helo=tonnant.bos.jonmasters.org) by edison.jonmasters.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hke0d-0003pR-Ii; Tue, 09 Jul 2019 00:29:27 +0000 From: Jon Masters To: "qi.fuli@fujitsu.com" , Will Deacon Cc: Will Deacon , "indou.takao@fujitsu.com" , "linux-doc@vger.kernel.org" , "peterz@infradead.org" , Catalin Marinas , Jonathan Corbet , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" References: <20190617143255.10462-1-indou.takao@jp.fujitsu.com> <20190617170328.GJ30800@fuggles.cambridge.arm.com> <20190627102724.vif6zh6zfqktpmjx@willie-the-truck> <5999ed84-72d0-9d42-bf7d-b8d56eaa4d4a@jp.fujitsu.com> <675313fe-007b-c850-d730-a629b82ccfc8@jonmasters.org> Message-ID: Date: Mon, 8 Jul 2019 20:29:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <675313fe-007b-c850-d730-a629b82ccfc8@jonmasters.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 50.195.43.97 X-SA-Exim-Mail-From: jcm@jonmasters.org Subject: Re: [PATCH 0/2] arm64: Introduce boot parameter to disable TLB flush instruction within the same inner shareable domain X-SA-Exim-Version: 4.2.1 (built Sun, 08 Nov 2009 07:31:22 +0000) X-SA-Exim-Scanned: Yes (on edison.jonmasters.org) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 7/8/19 8:25 PM, Jon Masters wrote: > On 7/2/19 10:45 PM, qi.fuli@fujitsu.com wrote: > >> However, we found that with the increase of that the TLB flash was called, >> the noise was also increasing. Here we understood that the cause of this >> issue is the implementation of Linux's TLB flush for arm64, especially use of >> TLBI-is instruction which is a broadcast to all processor core on the system. > > Are you saying that for a microbenchmark in which very large numbers of > threads are created and destroyed rapidly there are a large number of > associated tlb range flushes which always use broadcast TLBIs? > > If that's the case, and the hardware doesn't do any ASID filtering and > each TLBI results in a DVM to every PE, would it make sense to look at > whether there are ways to improve batching/switch to an IPI approach > rather than relying on broadcasts, as a more generic solution? What I meant was a heuristic to do this automatically, rather than via a command line. Jon.