linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Atish Patra <atish.patra@wdc.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Anup Patel <Anup.Patel@wdc.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v4 5/5] riscv: implement IPI-based remote TLB shootdown
Date: Thu, 28 Mar 2019 16:47:36 +0000	[thread overview]
Message-ID: <bf1771ca-6bb9-0740-87e4-3ef91e680bf4@garyguo.net> (raw)
In-Reply-To: <20190328163647.GA6577@infradead.org>



On 28/03/2019 16:36, Christoph Hellwig wrote:
>>>
>>> I think Anup now fixes OpenSBI.  Do you have benchmarks vs BBL,
>>> old OpenSBI and new OpenSBI?
>>>
>> See the cover letter. OpenSBI's code hasn't been made into stable, and
>> it has race conditions now.
> 
> Well, I'd still like to know numbers.  That is how people generally
> justify more complex code that claims to be more optimal :)
> 
No visible difference on QEMU, as all SFENCE.VMAs are global so we 
doesn't save anything, and the added cost of doing IPI is barely visible.

Don't have a board so can't test it out.

The main gain is to allow hardware devs to test their TLB implementation 
with Linux. If OpenSBI implements this properly we don't probably need 
the IPI code I guess.

>>> local_flush_tlb_range?
>>>
>> We don't have the VMA structures now so no. This is related to future
>> ASID patch as well.
> 
> Well, sprinkling inline assembly all over is generally not a good idea,
> so I'd like to have some helper.  And as pointed out before, IFF we pass
> an asid instead of the vma to local_flush_tlb_page once ASID support
> is added local_flush_tlb_page would nicely do that job.  If we really
> want another indirection it could be local_flush_tlb_page_asid instead,
> but I don't really see the point.
> 
Caller of local_flush_tlb_page (and the non-local) version shouldn't 
care about ASID. They only care about a particular MM. flush_tlb_page 
always takes a MM as argument and I see no point about why we shouldn't 
in the local version.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-03-28 16:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-27  0:41 [PATCH v4 0/5] TLB/I$ flush cleanups and improvements Gary Guo
2019-03-27  0:41 ` [PATCH v4 1/5] riscv: move flush_icache_{all,mm} to cacheflush.c Gary Guo
2019-03-27  7:06   ` Christoph Hellwig
2019-03-28  6:45   ` Anup Patel
2019-03-27  0:41 ` [PATCH v4 3/5] riscv: fix sbi_remote_sfence_vma{,_asid} Gary Guo
2019-03-27  7:08   ` Christoph Hellwig
2019-03-28  6:47   ` Anup Patel
2019-03-27  0:41 ` [PATCH v4 4/5] riscv: rewrite tlb flush for performance Gary Guo
2019-03-27  7:25   ` Christoph Hellwig
2019-03-27 13:56     ` Gary Guo
2019-03-28 16:17       ` Christoph Hellwig
2019-03-28 16:39         ` Gary Guo
2019-03-28 16:55           ` Christoph Hellwig
2019-03-27  0:41 ` [PATCH v4 2/5] riscv: move switch_mm to its own file Gary Guo
2019-03-27  7:08   ` Christoph Hellwig
2019-03-27  7:18   ` Christoph Hellwig
2019-03-28  6:47   ` Anup Patel
2019-03-27  0:41 ` [PATCH v4 5/5] riscv: implement IPI-based remote TLB shootdown Gary Guo
2019-03-27  7:31   ` Christoph Hellwig
2019-03-27 14:03     ` Gary Guo
2019-03-28 16:36       ` Christoph Hellwig
2019-03-28 16:47         ` Gary Guo [this message]
2019-03-28 16:57           ` Christoph Hellwig
2019-03-28  6:50   ` Anup Patel
2019-04-10  7:04 ` [PATCH v4 0/5] TLB/I$ flush cleanups and improvements Christoph Hellwig
2019-04-10  9:01   ` Anup Patel
2019-04-10 10:11     ` Christoph Hellwig
2019-04-10 10:22       ` Anup Patel
2019-04-11  1:24         ` 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=bf1771ca-6bb9-0740-87e4-3ef91e680bf4@garyguo.net \
    --to=gary@garyguo.net \
    --cc=Anup.Patel@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=atish.patra@wdc.com \
    --cc=hch@infradead.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    /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;
as well as URLs for NNTP newsgroup(s).