From: Gary Guo <gary@garyguo.net>
To: Anup Patel <anup@brainfault.org>
Cc: Anup Patel <Anup.Patel@wdc.com>,
Palmer Dabbelt <palmer@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Atish Patra <Atish.Patra@wdc.com>,
Christoph Hellwig <hch@infradead.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Mike Rapoport <rppt@linux.ibm.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] RISC-V: Implement ASID allocator
Date: Wed, 27 Mar 2019 13:38:24 +0000 [thread overview]
Message-ID: <49628dc9-c56d-6b60-9520-e4eb0e3b3424@garyguo.net> (raw)
In-Reply-To: <CAAhSdy1+rc9ge02uqNvse5Z6XmDxsRH0G=5GnMsh+6m1LMLFYg@mail.gmail.com>
On 27/03/2019 11:42, Anup Patel wrote:
> On Wed, Mar 27, 2019 at 4:57 PM Gary Guo <gary@garyguo.net> wrote:
>>
>> Hi Anup,
>>
>> This won't work in an actual hardware with ASID support. There're more
>
> Can you elaborate why >
>
> This implementation is based on Linux ARM64 ASID allocator which is
> tested for large number of CPUs on real HW.
>
>> interactions with TLB flushes that need to be considered. You won't see
>
> Yap, already considered. Please point me to unhandled case.
>
When memory mapping is changed, you need to flush it from all cores that
previously have that process executed, etc. Our patches both take
inspiration from ARM's code, but the major difference between my code is
handling of cache invalidations, see my code's cache_mask, etc. This is
actually the most error-prone part, and I spent more time trying to find
an optimal solution for this than porting the ASID allocator. The major
difference is that ARM has a much more expressive sets of TLB flush
instructions compared to RISC-V.
>
>> this on both QEMU and SiFive board, as QEMU does not have ASID, so it
>> pretends that ASID is supported by just flushing its TLB everytime you
>
> Nope, it does not. It detects whether ASID is supported or not. If supported
> it will also figure-out number of ASID bits supported by HW.
>
Except that you can detect that QEMU supports ASID, but actually it does
not. However QEMU is still correct because it always flush TLB when you
set SATP/SPTBR. You won't be able to find out bugs in your code by just
testing on QEMU.
> SiFive board does not have ASID bits so this implementation successfully
> detects that number of ASID bits are 0 and fallbacks to original way of
> local TLB flushes. >
>> change sptbr. I suspect the performance gain you see is just due to
>> saved TLB flush as TLB flush is super expensive in QEMU (all translation
>> block jumps need to be cleared).
>
> Yes, performance gain is due to saved TLB flushes.
>
> On HW which supports ASID bits, we will see more performance
> improvements. >
A hardware TLB flush is cheaper than QEMU' TLB flush. As no hardware
supports ASID at the moment the performance gain is minimal.
>>
>> I have my version here https://github.com/nbdd0121/linux/tree/asid. I
>> haven't done code cleanups yet, but this version has correctness of its
>> ASID code tested on our TLB simulator tool (which unfortunately I can't
>> share right now as it involves with unpublished works).
>
> Except few minor differences. You version of ASID allocator is same as
> mine. In fact there are lot of similar code framgements in your version
> compared to Linux ARM64 as well. I am sure this patch will work for you.
> >>
>> In fact my submit my previous patch series exactly as the basis of this
>> patch.
>
> This patch is based your patch series so I suggest you take this patch
> and try it on your simulator.
>
I've tested, and it does not boot.
next prev parent reply other threads:[~2019-03-27 13:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-27 10:02 Anup Patel
2019-03-27 11:27 ` Gary Guo
2019-03-27 11:42 ` Anup Patel
2019-03-27 13:38 ` Gary Guo [this message]
2019-03-27 14:10 ` Anup Patel
2019-03-27 13:42 ` Gary Guo
2019-03-27 14:02 ` Anup Patel
2019-03-27 14:09 ` Gary Guo
2019-03-27 14:12 ` Anup Patel
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=49628dc9-c56d-6b60-9520-e4eb0e3b3424@garyguo.net \
--to=gary@garyguo.net \
--cc=Anup.Patel@wdc.com \
--cc=Atish.Patra@wdc.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@sifive.com \
--cc=paul.walmsley@sifive.com \
--cc=rppt@linux.ibm.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
all inboxes | Powered by JetHome®