Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp498364ybl; Wed, 21 Aug 2019 23:54:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqyy87l8cG8YWzD3/ZatoGZHRJfZr9C5iBMZo0tQ/l6yaqJ8eZTUOQm841V3NuQo6+E0DZKc X-Received: by 2002:a17:902:166:: with SMTP id 93mr38408110plb.195.1566456889596; Wed, 21 Aug 2019 23:54:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566456889; cv=none; d=google.com; s=arc-20160816; b=mKTBkRYRYg539OC1DbDlNt6etvDo9DtzJSvsg8/w0YTjNQ/frQeeQwHVnlgWR1xkTR ZtB5WDkqUsohO8tD3BhBlOXh1xyDvW/goubAbz1J5lc/enDEUqIum2nAOBJQURLOO35B CFv7w9tZPAh4mhTas9J/+qcsrWIoZ/CZ7+lTd7OldJzTZG1p50CZVtTEOGHrmx5eJaMY opH5hL3DiPrvl++nhQvUpuqh2kGaEw2V9g/bke/KDdeHzI4cQh8KLV6xv4nCLUL6mc6L rYxw6UARfTPgn+fwMAV4XkAUHoOhZZCxl33JnQE9P6RXM8Dhd9K/YzO/29qur4QV7sy6 yGAw== 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=BmeyGUYUclkaCtuhcndczX+xGlhtHqSLxi3m+e4vEJM=; b=Z6rzJUOhfi8HZV9ROn+mbmBRRoGeME3eS4hJR5ogKWdHsSD4jlSrLKFpKJCYEDhnOF 2nLHH7s/IfMoRSwQacGby66Fxd5iQyVZYCQ+4QxwkWMMYfFO7Zo0gqX8vgMAgVSlQOmf mJtS3biYMICOvs1fUDCDjE8Oe51SisaMWtmA0ETLjIywMPGNkbJJzaXhK8iPJX24t57t DsK0uOsdfjhKH3ToeFTLqeed2tc+rYKDxOW61+Nohn/qzBdQF771Rtgt5OHmyzKIdrXd bEuHOtIfXWis46P6n1yzMq4n7zVX4k0u3DFohY4D4gW7aVqteJUJhleYwRFJXzXil99p Z8uA== 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 d1si17516491pfo.72.2019.08.21.23.54.34; Wed, 21 Aug 2019 23:54:49 -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 S1730459AbfHVE1V (ORCPT + 99 others); Thu, 22 Aug 2019 00:27:21 -0400 Received: from verein.lst.de ([213.95.11.211]:43536 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728870AbfHVE1V (ORCPT ); Thu, 22 Aug 2019 00:27:21 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id ED3C668C4E; Thu, 22 Aug 2019 06:27:17 +0200 (CEST) Date: Thu, 22 Aug 2019 06:27:17 +0200 From: "hch@lst.de" To: Atish Patra Cc: "hch@lst.de" , "paul.walmsley@sifive.com" , "linux-riscv@lists.infradead.org" , "schwab@linux-m68k.org" , Anup Patel , "linux-kernel@vger.kernel.org" , "palmer@sifive.com" , "aou@eecs.berkeley.edu" Subject: Re: [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible. Message-ID: <20190822042717.GA14076@lst.de> References: <20190822004644.25829-1-atish.patra@wdc.com> <20190822004644.25829-2-atish.patra@wdc.com> <20190822014642.GA11922@lst.de> <0f66583404f89ab2bd6c264ba653364ab8a3160e.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f66583404f89ab2bd6c264ba653364ab8a3160e.camel@wdc.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 22, 2019 at 04:01:24AM +0000, Atish Patra wrote: > The downside of this is that for every !cmask case in true SMP (more > common probably) it will execute 2 extra cpumask instructions. As > tlbflush path is in performance critical path, I think we should favor > more common case (SMP with more than 1 core). Actually, looking at both the current mainline code, and the code from my cleanups tree I don't think remote_sfence_vma / __sbi_tlb_flush_range can ever be called with NULL cpumask, as we always have a valid mm. So this is a bit of a moot point, and we can drop andling that case entirely. With that we can also use a simple if / else for the local cpu only vs remote case. Btw, what was the reason you didn't like using cpumask_any_but like x86, which should be more efficient than cpumask_test_cpu + hweigt?