From: David Laight <David.Laight@ACULAB.COM>
To: 'Palmer Dabbelt' <palmer@dabbelt.com>,
"akira.tsukamoto@gmail.com" <akira.tsukamoto@gmail.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3 1/1] riscv: __asm_copy_to-from_user: Optimize unaligned memory access and pipeline stall
Date: Wed, 7 Jul 2021 10:07:16 +0000 [thread overview]
Message-ID: <7f6e56390954403fb07a1c606fbc7e6d@AcuMS.aculab.com> (raw)
In-Reply-To: <mhng-f4c7d64b-f4e9-491a-8868-bc1baa7a72a7@palmerdabbelt-glaptop>
...
> > + fixup REG_L a4, 0(a1), 10f
> > + fixup REG_L a5, SZREG(a1), 10f
> > + fixup REG_L a6, 2*SZREG(a1), 10f
> > + fixup REG_L a7, 3*SZREG(a1), 10f
> > + fixup REG_L t1, 4*SZREG(a1), 10f
> > + fixup REG_L t2, 5*SZREG(a1), 10f
> > + fixup REG_L t3, 6*SZREG(a1), 10f
> > + fixup REG_L t4, 7*SZREG(a1), 10f
> > + fixup REG_S a4, 0(a0), 10f
> > + fixup REG_S a5, SZREG(a0), 10f
> > + fixup REG_S a6, 2*SZREG(a0), 10f
> > + fixup REG_S a7, 3*SZREG(a0), 10f
> > + fixup REG_S t1, 4*SZREG(a0), 10f
> > + fixup REG_S t2, 5*SZREG(a0), 10f
> > + fixup REG_S t3, 6*SZREG(a0), 10f
> > + fixup REG_S t4, 7*SZREG(a0), 10f
>
> This seems like a suspiciously large unrolling factor, at least without
> a fallback. My guess is that some workloads will want some smaller
> unrolling factors, but given that we run on these single-issue in-order
> processors it's probably best to have some big unrolling factors as well
> since they're pretty limited WRT integer bandwidth.
But a single-issue cpu is unlikely to have an 8 clock data delay.
OTOH a cpu than can do concurrent memory read and write might
not have enough 'out of order' capability to do so with the above loop.
You may want to interleave the reads and writes - starting with
two or three reads (possibly with the extra ones outside the loop).
I don't know the microarchitectures well enough (well at all)
to know the exact pitfalls.
The very simple cpu might have the same 'issue' the Nios2 has
(another MIPS clone fpga soft cpu) where there can be a pipeline
stall between a write and read.
I doubt the non-trivial riscv have that issue though.
> > + addi a0, a0, 8*SZREG
> > + addi a1, a1, 8*SZREG
> > + bltu a0, t0, 2b
For a dual-issue cpu you want to move the two 'addi' higher
up the loop so that they are 'free'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-07-07 10:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 12:37 [PATCH v3 0/1] riscv: improving uaccess with logs from network bench Akira Tsukamoto
2021-06-23 12:40 ` [PATCH v3 1/1] riscv: __asm_copy_to-from_user: Optimize unaligned memory access and pipeline stall Akira Tsukamoto
2021-07-06 23:16 ` Palmer Dabbelt
2021-07-07 10:07 ` David Laight [this message]
2021-07-10 1:49 ` Guenter Roeck
2021-07-13 18:10 ` Geert Uytterhoeven
2021-07-15 6:20 ` Akira Tsukamoto
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=7f6e56390954403fb07a1c606fbc7e6d@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akira.tsukamoto@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@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).