Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8824696ybi; Tue, 23 Jul 2019 16:06:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqynaK34GmEDCSIhpOhhFcoH9crP132z8MEkG3xhgSMXrFR9l3Y0AYM8vCRonjrli3cZ/oA2 X-Received: by 2002:a17:902:7791:: with SMTP id o17mr83850117pll.27.1563923162812; Tue, 23 Jul 2019 16:06:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563923162; cv=none; d=google.com; s=arc-20160816; b=JH83qFYSWkTtV3d437KNNT9ZzLJBPbU0YtNqgpAQJKOAbwPFpSpWSgPEU0K5doLzGk PGZO7iSWNgbNXw2w2A1fwjPVTku5XVPitLkKbgr5vwV98iIMi/yAuRF8doiDwpEeS8m8 MJqfH4+yX4ZD/FplyD/sWLrPnmncydB+jZnfxXaATB9nH0DFe6HR/pM02iqWLSR4B5iF GQb56DaT+/RBDUaI/2iAv9qebcMeWofzOF8P8taYOpw2jViJqf0hOYAyhcKl2D47Fmav Wrynncpmz+d0/COIXmVkKVB/5295OkwTtI8iqxIV/xjdZFEteje/N9+xlth3e0boNpaO tLdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9Z+7DucTIaCXLHbeNfuOShl7mDpyZB6ZSf7WmlHSr6k=; b=ow8+pTCQuI7ry24KvAoRp7McqUL0+pTngJcE2fpsuUEdphX7tBHPkSG8fApYfV9Ryz YQvQ1mYlYtgkaI0mvOyL/eVyq0eyJfTXOe9/ei/OwZfWPnbtQrr2Te7YSJB2gvs2UBfi BctWpsUzbE+yGkxuc/gLoFjpVmZoKUV+019gtWElAxTxBWHabolph6Xz49ex7YK9RD/i +BluiGU9qXFvxGlyIDw+GBmnvpiUDtM/a5aut0ZzUsaNfublHa2mBuf5GTPHWFBgocQY mMf83jxlCPhHsPjzDgDFlPdtwqp8wcfeJ1vrKgHq1aGQWSXkYR3v8FBCVPOnJTZjLsa/ YBgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 145si12580317pfb.262.2019.07.23.16.05.47; Tue, 23 Jul 2019 16:06:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389567AbfGWMLZ (ORCPT + 99 others); Tue, 23 Jul 2019 08:11:25 -0400 Received: from foss.arm.com ([217.140.110.172]:53734 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729441AbfGWMLZ (ORCPT ); Tue, 23 Jul 2019 08:11:25 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 450DC337; Tue, 23 Jul 2019 05:11:24 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 261F03F71F; Tue, 23 Jul 2019 05:11:23 -0700 (PDT) Date: Tue, 23 Jul 2019 13:11:21 +0100 From: Catalin Marinas To: Takao Indoh Cc: Jonathan Corbet , Will Deacon , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, QI Fuli , Takao Indoh Subject: Re: [PATCH 2/2] arm64: tlb: Add boot parameter to disable TLB flush within the same inner shareable domain Message-ID: <20190723121120.GB16928@arrakis.emea.arm.com> References: <20190617143255.10462-1-indou.takao@jp.fujitsu.com> <20190617143255.10462-3-indou.takao@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190617143255.10462-3-indou.takao@jp.fujitsu.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 17, 2019 at 11:32:55PM +0900, Takao Indoh wrote: > From: Takao Indoh > > This patch adds new boot parameter 'disable_tlbflush_is' to disable TLB > flush within the same inner shareable domain for performance tuning. > > In the case of flush_tlb_mm() *without* this parameter, TLB entry is > invalidated by __tlbi(aside1is, asid). By this instruction, all CPUs within > the same inner shareable domain check if there are TLB entries which have > this ASID, this causes performance noise, especially at large-scale HPC > environment, which has more than thousand nodes with low latency > interconnect. > > When this new parameter is specified, TLB entry is invalidated by > __tlbi(aside1, asid) only on the CPUs specified by mm_cpumask(mm). > Therefore TLB flush is done on minimal CPUs and performance problem does > not occur. > > Signed-off-by: QI Fuli > Signed-off-by: Takao Indoh [...] > +void flush_tlb_mm(struct mm_struct *mm) > +{ > + if (disable_tlbflush_is) > + on_each_cpu_mask(mm_cpumask(mm), ipi_flush_tlb_mm, > + (void *)mm, true); > + else > + __flush_tlb_mm(mm); > +} Could we try instead to call a _nosync variant here when cpumask_weight() is 1 or the *IS if greater than 1 and avoid the IPI? Will tried this in the past but because of the task placement after fork()+execve(), I think we always ended up with a weight of 2 in the child process. Your first patch "solves" this by flushing the TLBs on context switch (bar the CnP case). Can you give it a try to see if it improves things? At least it's a starting point for further investigation. I fully agree with Will that we don't want two different TLB handling implementations in the arm64 kernel and even less desirable to have a command line option. Thanks. -- Catalin