Optimize RISC-V copyin(9)/copyout(9) routines

[mhorne063_gmail.com]

Summary

The existing copyin(9) and copyout(9) routines on RISC-V perform only a
simple byte-by-byte copy. Improve their performance by performing
word-sized copies where possible.

Overall approach: For best performance, all load's and stores must occur
on their native boundary, i.e. a 64-bit load must occur on a 64-bit
aligned address. Misaligned loads and stores are possible, but they
require trapping into the SBI, which introduces an even bigger overhead.
Therefore, we will perform word-sized loads and stores only where
possible.

For cases where the source and destination addresses are not aligned to
each other, we have no choice but to do a byte-by- byte copy for the
entire thing. So long as this is not the case, then we can perform word
copy for some or all of the buffer. In some cases this will require byte
copy at the beginning or end to account for addresses that are not
initially word-aligned or any remainder due to buffer length.

Test Plan

Boots successfully to the login prompt.

I will perform a few simple tests to get some numbers on the performance improvement.

I could also try running the copyin tests, but I'm not sure if I'm set up to do that yet.

[markj]

sys/riscv/include/riscvreg.h

159

XLEN is defined to be the width of the CPU's general purpose registers - what's the reason for adding a new constant?

[mhorne063_gmail.com]

sys/riscv/include/riscvreg.h

159

Whoops, I had a comment about this but didn't submit it.

The spec uses XLEN to refer to the GPR width in bits. In my opinion, defining it here in bytes is a miss-use of the name.
A quick grep shows that it isn't referenced by any existing code, so rather than using it in mine I added the new constant.

Perhaps we could adjust it to XLEN = 64, and rename REG_SIZE to XLEN_BYTES? Having a proper XLEN in bits would be useful for eventually making some existing constants width-agnostic.

[markj]

sys/riscv/include/riscvreg.h

159

Ahh, I see. Indeed, we don't use XLEN, but there is the compiler-provided __riscv_xlen which has a couple of usages.

I like the suggestion of fixing XLEN's value (probably just define XLEN to be __riscv_xlen?) and introducing XLEN_BYTES.

[mhorne063_gmail.com]

Adjust XLEN constant names and values.

[markj]

You can add your copyright to this file if you feel so inclined.

[mhorne063_gmail.com]

In D18851#403510, @markj wrote:

You can add your copyright to this file if you feel so inclined.

Sure, might as well :)

sys/riscv/include/riscvreg.h

 .Op Fl t Ar trstr
 .Ar command
 .Sh DESCRIPTION
 The
 .Nm
 utility enables kernel trace logging for the specified processes.
 Kernel trace data is logged to the file
 .Pa ktrace.out .
-The kernel operations that are traced include system calls,
+The kernel operations that are traced include system calls
+.Pq see Xr intro 2 ,
 .Xr namei 9
-translations, signal processing, and
+translations, signal processing
+.Pq Xr sigaction 2 ,
+and
 .Tn I/O .
 .Pp
 Once tracing is enabled on a process, trace data will be logged until
 either the process exits or the trace point is cleared.
 A traced process can generate enormous amounts of log data quickly;
 It is strongly suggested that users memorize how to disable tracing before
 attempting to trace a process.
 The following command is sufficient to disable tracing on all user-owned

 .Dl $ ktrace -c -f tracedata
 .Pp
 Disable tracing of all user-owned processes:
 .Dl $ ktrace -C
 .Sh SEE ALSO
 .Xr dtrace 1 ,
 .Xr kdump 1 ,
 .Xr truss 1 ,
+.Xr intro 2 ,
 .Xr ktrace 2 ,
+.Xr sigaction 2 ,
 .Xr utrace 2 ,
 .Xr capsicum 4 ,
 .Xr namei 9
 .Sh HISTORY
 The
 .Nm
 command appeared in
 .Bx 4.4 .
 .Sh BUGS
 Only works if
 .Ar trfile
 is a regular file.

sys/riscv/riscv/copyinout.S

 .Op Fl t Ar trstr
 .Ar command
 .Sh DESCRIPTION
 The
 .Nm
 utility enables kernel trace logging for the specified processes.
 Kernel trace data is logged to the file
 .Pa ktrace.out .
-The kernel operations that are traced include system calls,
+The kernel operations that are traced include system calls
+.Pq see Xr intro 2 ,
 .Xr namei 9
-translations, signal processing, and
+translations, signal processing
+.Pq Xr sigaction 2 ,
+and
 .Tn I/O .
 .Pp
 Once tracing is enabled on a process, trace data will be logged until
 either the process exits or the trace point is cleared.
 A traced process can generate enormous amounts of log data quickly;
 It is strongly suggested that users memorize how to disable tracing before
 attempting to trace a process.
 The following command is sufficient to disable tracing on all user-owned

 .Dl $ ktrace -c -f tracedata
 .Pp
 Disable tracing of all user-owned processes:
 .Dl $ ktrace -C
 .Sh SEE ALSO
 .Xr dtrace 1 ,
 .Xr kdump 1 ,
 .Xr truss 1 ,
+.Xr intro 2 ,
 .Xr ktrace 2 ,
+.Xr sigaction 2 ,
 .Xr utrace 2 ,
 .Xr capsicum 4 ,
 .Xr namei 9
 .Sh HISTORY
 The
 .Nm
 command appeared in
 .Bx 4.4 .
 .Sh BUGS
 Only works if
 .Ar trfile
 is a regular file.