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 450EA7D90D for ; Tue, 9 Jul 2019 01:03:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726375AbfGIBCd (ORCPT ); Mon, 8 Jul 2019 21:02:33 -0400 Received: from edison.jonmasters.org ([173.255.233.168]:59278 "EHLO edison.jonmasters.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726279AbfGIBCb (ORCPT ); Mon, 8 Jul 2019 21:02:31 -0400 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 1hkdxB-0003Xo-BL; Tue, 09 Jul 2019 00:25:53 +0000 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> From: Jon Masters Message-ID: <675313fe-007b-c850-d730-a629b82ccfc8@jonmasters.org> Date: Mon, 8 Jul 2019 20:25:52 -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: <5999ed84-72d0-9d42-bf7d-b8d56eaa4d4a@jp.fujitsu.com> 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/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? Jon.