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)
WARNING: multiple messages have this Message-ID (diff)
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) _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-07-07 10:07 UTC|newest] Thread overview: 14+ 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:37 ` 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-06-23 12:40 ` Akira Tsukamoto 2021-07-06 23:16 ` Palmer Dabbelt 2021-07-06 23:16 ` Palmer Dabbelt 2021-07-07 10:07 ` David Laight [this message] 2021-07-07 10:07 ` David Laight 2021-07-10 1:49 ` Guenter Roeck 2021-07-10 1:49 ` Guenter Roeck 2021-07-13 18:10 ` Geert Uytterhoeven 2021-07-13 18:10 ` Geert Uytterhoeven 2021-07-15 6:20 ` Akira Tsukamoto 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.