[PATCH v3 1/1] riscv: __asm_copy_to-from_user: Optimize unaligned memory access and pipeline stall
David Laight
David.Laight at ACULAB.COM
Wed Jul 7 03:07:16 PDT 2021
...
> > + 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)
More information about the linux-riscv
mailing list