mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "hch@lst.de" <hch@lst.de>
To: Atish Patra <Atish.Patra@wdc.com>
Cc: "hch@lst.de" <hch@lst.de>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"schwab@linux-m68k.org" <schwab@linux-m68k.org>,
	Anup Patel <Anup.Patel@wdc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible.
Date: Thu, 22 Aug 2019 06:27:17 +0200	[thread overview]
Message-ID: <20190822042717.GA14076@lst.de> (raw)
In-Reply-To: <0f66583404f89ab2bd6c264ba653364ab8a3160e.camel@wdc.com>

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?

  reply	other threads:[~2019-08-22  4:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22  0:46 [PATCH v3 0/3] Optimize tlbflush path Atish Patra
2019-08-22  0:46 ` [PATCH v3 1/3] RISC-V: Issue a local tlbflush if possible Atish Patra
2019-08-22  1:46   ` Christoph Hellwig
2019-08-22  4:01     ` Atish Patra
2019-08-22  4:27       ` hch [this message]
2019-08-22  5:39         ` Atish Patra
2019-08-22  0:46 ` [PATCH v3 2/3] RISC-V: Issue a tlb page flush " Atish Patra
2019-08-22  1:50   ` Christoph Hellwig
2019-08-22  4:02     ` Atish Patra
2019-08-22  0:46 ` [PATCH v3 3/3] RISC-V: Do not invoke SBI call if cpumask is empty Atish Patra
2019-08-22  1:51   ` Christoph Hellwig
2019-08-22  4:23     ` Atish Patra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190822042717.GA14076@lst.de \
    --to=hch@lst.de \
    --cc=Anup.Patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome