| Message ID | 5a5c07ac-8c11-79d3-46a3-a255d4148f76@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | riscv: improving uaccess with logs from network bench | expand |
On 19/06/2021 12:21, Akira Tsukamoto wrote: > Optimizing copy_to_user and copy_from_user. > > I rewrote the functions in v2, heavily influenced by Garry's memcpy > function [1]. > The functions must be written in assembler to handle page faults manually > inside the function. > > With the changes, improves in the percentage usage and some performance > of network speed in UDP packets. > Only patching copy_user. Using the original memcpy. > > All results are from the same base kernel, same rootfs and same > BeagleV beta board. Is there a git tree for these to try them out? > Comparison by "perf top -Ue task-clock" while running iperf3. > > --- TCP recv --- > * Before > 40.40% [kernel] [k] memcpy > 33.09% [kernel] [k] __asm_copy_to_user > * After > 50.35% [kernel] [k] memcpy > 13.76% [kernel] [k] __asm_copy_to_user > > --- TCP send --- > * Before > 19.96% [kernel] [k] memcpy > 9.84% [kernel] [k] __asm_copy_to_user > * After > 14.27% [kernel] [k] memcpy > 7.37% [kernel] [k] __asm_copy_to_user > > --- UDP send --- > * Before > 25.18% [kernel] [k] memcpy > 22.50% [kernel] [k] __asm_copy_to_user > * After > 28.90% [kernel] [k] memcpy > 9.49% [kernel] [k] __asm_copy_to_user > > --- UDP recv --- > * Before > 44.45% [kernel] [k] memcpy > 31.04% [kernel] [k] __asm_copy_to_user > * After > 55.62% [kernel] [k] memcpy > 11.22% [kernel] [k] __asm_copy_to_user What's the memcpy figure in the above? Could you explain the figures please? > Processing network packets require a lot of unaligned access for the packet > header, which is not able to change the design of the header format to be > aligned. Isn't there an option to allow padding of network packets in the skbuff to make the fields aligned for architectures which do not have efficient unaligned loads (looking at you arm32). Has this been looked at? > And user applications call system calls with a large buffer for send/recf() > and sendto/recvfrom() to repeat less function calls for the optimization. > > v1 -> v2: > - Added shift copy > - Separated patches for readability of changes in assembler > - Using perf results > > [1] https://lkml.org/lkml/2021/2/16/778 > > Akira Tsukamoto (5): > riscv: __asm_to/copy_from_user: delete existing code > riscv: __asm_to/copy_from_user: Adding byte copy first > riscv: __asm_to/copy_from_user: Copy until dst is aligned address > riscv: __asm_to/copy_from_user: Bulk copy while shifting misaligned > data > riscv: __asm_to/copy_from_user: Bulk copy when both src dst are > aligned > > arch/riscv/lib/uaccess.S | 181 +++++++++++++++++++++++++++++++-------- > 1 file changed, 146 insertions(+), 35 deletions(-) I'm concerned that delete and then re-add is either going to make the series un-bisectable or leave a point where the kernel is very broken?
On 6/20/21 19:02, Ben Dooks wrote: > On 19/06/2021 12:21, Akira Tsukamoto wrote: >> Optimizing copy_to_user and copy_from_user. >> >> I rewrote the functions in v2, heavily influenced by Garry's memcpy >> function [1]. >> The functions must be written in assembler to handle page faults manually >> inside the function. >> >> With the changes, improves in the percentage usage and some performance >> of network speed in UDP packets. >> Only patching copy_user. Using the original memcpy. >> >> All results are from the same base kernel, same rootfs and same >> BeagleV beta board. > > Is there a git tree for these to try them out? Sure, please try. The kernel without the patch is starlight branch and the kernel with these patches is starlight-ua-new-up at https://github.com/mcd500/linux-jh7100 The starlight is maintained by Esmil where main development is happening. And the rootfs on beaglev is uploaded bellow. https://github.com/mcd500/Fedora_on_StarFive#custome-fedora-image To reproduce the results: (please customize with your ip addreses) The command I used for iperf3. --- TCP recv --- ** on PC side, using default mtu 1500 $ iperf3 -c 192.168.1.112 ** on riscv beaglev side, using default mtu 1500 [root@fedora-starfive ~]# iperf3 -s --- TCP send --- ** on PC side, using default mtu 1500 $ iperf3 -s ** on riscv beaglev side, using default mtu 1500 [root@fedora-starfive ~]# iperf3 -c 192.168.1.153 --- UDP send --- ** on PC side first, changing mtu size from 1500 to 9000 $ sudo ifconfig eth0 down $ sudo ifconfig eth0 mtu 9000 up $ iperf3 -s ** on riscv beaglev, No changing the mtu size on riscv beaglev [root@fedora-starfive ~]# iperf3 -u -b 1000M --length 50000 -c 192.168.1.153 --- UDP recv --- ** on PC side first, changing mtu size to 9000 $ sudo ifconfig eth0 down $ sudo ifconfig eth0 mtu 9000 up $ iperf3 -u -b 1000M --length 6500 -c 192.168.1.112 ** on riscv beaglev side, changing mtu size to 9000 too [root@fedora-starfive ~]# sudo ifconfig eth0 down [root@fedora-starfive ~]# sudo ifconfig eth0 mtu 9000 up [root@fedora-starfive ~]# iperf3 -s The perf: $ sudo perf top -Ue task-clock after login with ssh. > >> Comparison by "perf top -Ue task-clock" while running iperf3. >> >> --- TCP recv --- >> * Before >> 40.40% [kernel] [k] memcpy >> 33.09% [kernel] [k] __asm_copy_to_user >> * After >> 50.35% [kernel] [k] memcpy >> 13.76% [kernel] [k] __asm_copy_to_user >> >> --- TCP send --- >> * Before >> 19.96% [kernel] [k] memcpy >> 9.84% [kernel] [k] __asm_copy_to_user >> * After >> 14.27% [kernel] [k] memcpy >> 7.37% [kernel] [k] __asm_copy_to_user >> >> --- UDP send --- >> * Before >> 25.18% [kernel] [k] memcpy >> 22.50% [kernel] [k] __asm_copy_to_user >> * After >> 28.90% [kernel] [k] memcpy >> 9.49% [kernel] [k] __asm_copy_to_user >> >> --- UDP recv --- >> * Before >> 44.45% [kernel] [k] memcpy >> 31.04% [kernel] [k] __asm_copy_to_user >> * After >> 55.62% [kernel] [k] memcpy >> 11.22% [kernel] [k] __asm_copy_to_user > > What's the memcpy figure in the above? > Could you explain the figures please? It is the output of "perf top -Ue task-clock" while performing the iperf3 which I described above. Showing which functions are causing the most overhead inside the kernel during running iperf3 in cpu usage. The two biggest culprits were memcpy and __asm_copy_to_user showing high cpu usage, and this is the reason I listed the two. Initially this discussion started with Gary's memcpy patch on this list. I will write more details bellow. > >> Processing network packets require a lot of unaligned access for the packet >> header, which is not able to change the design of the header format to be >> aligned. > > Isn't there an option to allow padding of network packets > in the skbuff to make the fields aligned for architectures > which do not have efficient unaligned loads (looking at you > arm32). Has this been looked at? I am trying at 64bit risc-v beaglev beta board. My understanding of skbuff is that it is for aligning data when the handling inside the kernel. It would help if memcpy and __asm_copy_to_user were not causing such a huge percentage. This patch is against copy_to_user and copy_from_user purely used for copying between kernel space and user space. By looking the overhead on perf, the cpu usage is increasing on copy_to_user because the user app (iperf3 here) uses socket API with large packet size. I used to use maximum buffer size of mtu for reduce the number of calling recvform() sendto() for UDP programing too. And most of the network programmer probably do the same. > >> And user applications call system calls with a large buffer for send/recf() >> and sendto/recvfrom() to repeat less function calls for the optimization. >> >> v1 -> v2: >> - Added shift copy >> - Separated patches for readability of changes in assembler >> - Using perf results >> >> [1] https://lkml.org/lkml/2021/2/16/778 >> >> Akira Tsukamoto (5): >> riscv: __asm_to/copy_from_user: delete existing code >> riscv: __asm_to/copy_from_user: Adding byte copy first >> riscv: __asm_to/copy_from_user: Copy until dst is aligned address >> riscv: __asm_to/copy_from_user: Bulk copy while shifting misaligned >> data >> riscv: __asm_to/copy_from_user: Bulk copy when both src dst are >> aligned >> >> arch/riscv/lib/uaccess.S | 181 +++++++++++++++++++++++++++++++-------- >> 1 file changed, 146 insertions(+), 35 deletions(-) > > I'm concerned that delete and then re-add is either going to make > the series un-bisectable or leave a point where the kernel is very > broken? I completely agree and understand. The only reason I split the patches is because of the comments in the other thread. It definitely breaks the bisect. Once the content of this patch is understood and agreed, I will re-spin them in one patch, otherwise it will not boot when only individual patch is applied. The Gary's memcpy patch was posted a while ago, and even it has the best result in bench, it was not merged. When we were measuring network performance on beaglev beta board, the Gary's memcpy did have huge improvement. The patch was not easy to review and understand, but it really helps the network performance. By reading the discussion on his patch, I felt the first priority is able to be understood the cause of cpu usage and speed results. Please read the discussion by Gary, Palmer, Matteo, others and I in the list. Matteo is rewriting Gary's patch in C, which is better for maintainability and incorporate the wisdom of the optimization of the compiler. The user_copy are written in assembler or inline assembler, as I wrote. I just want to help making it better, so once the consensus are made, I will make them to one patch. Or I am fine somebody else comes out with better results. My attempt to do similar patches dates long time ago in 2002. https://linux-kernel.vger.kernel.narkive.com/zU6OFlI6/cft-patch-2-5-47-athlon-druon-much-faster-copy-user-function http://lkml.iu.edu/hypermail/linux/kernel/0211.2/0928.html Akira
On 19/06/2021 12:21, Akira Tsukamoto wrote: > Optimizing copy_to_user and copy_from_user. > > I rewrote the functions in v2, heavily influenced by Garry's memcpy > function [1]. > The functions must be written in assembler to handle page faults manually > inside the function. > > With the changes, improves in the percentage usage and some performance > of network speed in UDP packets. > Only patching copy_user. Using the original memcpy. > > All results are from the same base kernel, same rootfs and same > BeagleV beta board. > > Comparison by "perf top -Ue task-clock" while running iperf3. I did a quick test on a SiFive Unmatched with IO to an NVME. before: cached-reads=172.47MB/sec, buffered-reads=135.8MB/sec with-patch: cached-read=s177.54Mb/sec, buffered-reads=137.79MB/sec That was just one test run, so there was a small improvement. I am sort of surprised we didn't get more of a win from this. perf record on hdparm shows that it spends approx 15% cpu time in asm_copy_to_user. Does anyone have a benchmark for this which just looks at copy/to user? if not should we create one?
On 6/22/2021 5:30 PM, Ben Dooks wrote: > On 19/06/2021 12:21, Akira Tsukamoto wrote: >> Optimizing copy_to_user and copy_from_user. >> >> I rewrote the functions in v2, heavily influenced by Garry's memcpy >> function [1]. >> The functions must be written in assembler to handle page faults manually >> inside the function. >> >> With the changes, improves in the percentage usage and some performance >> of network speed in UDP packets. >> Only patching copy_user. Using the original memcpy. >> >> All results are from the same base kernel, same rootfs and same >> BeagleV beta board. >> >> Comparison by "perf top -Ue task-clock" while running iperf3. > > I did a quick test on a SiFive Unmatched with IO to an NVME. > > before: cached-reads=172.47MB/sec, buffered-reads=135.8MB/sec > with-patch: cached-read=s177.54Mb/sec, buffered-reads=137.79MB/sec > > That was just one test run, so there was a small improvement. I am > sort of surprised we didn't get more of a win from this. > > perf record on hdparm shows that it spends approx 15% cpu time in > asm_copy_to_user. Does anyone have a benchmark for this which just > looks at copy/to user? if not should we create one? Thanks for the result on the Unmatched with hdparm. Have you tried iperf3? The 15% is high, is it before or with-patch? Akira
On 22/06/2021 13:05, Akira Tsukamoto wrote: > On 6/22/2021 5:30 PM, Ben Dooks wrote: >> On 19/06/2021 12:21, Akira Tsukamoto wrote: >>> Optimizing copy_to_user and copy_from_user. >>> >>> I rewrote the functions in v2, heavily influenced by Garry's memcpy >>> function [1]. >>> The functions must be written in assembler to handle page faults manually >>> inside the function. >>> >>> With the changes, improves in the percentage usage and some performance >>> of network speed in UDP packets. >>> Only patching copy_user. Using the original memcpy. >>> >>> All results are from the same base kernel, same rootfs and same >>> BeagleV beta board. >>> >>> Comparison by "perf top -Ue task-clock" while running iperf3. >> >> I did a quick test on a SiFive Unmatched with IO to an NVME. >> >> before: cached-reads=172.47MB/sec, buffered-reads=135.8MB/sec >> with-patch: cached-read=s177.54Mb/sec, buffered-reads=137.79MB/sec >> >> That was just one test run, so there was a small improvement. I am >> sort of surprised we didn't get more of a win from this. >> >> perf record on hdparm shows that it spends approx 15% cpu time in >> asm_copy_to_user. Does anyone have a benchmark for this which just >> looks at copy/to user? if not should we create one? > > Thanks for the result on the Unmatched with hdparm. Have you tried > iperf3? I will see if there is iperf3 installed. I've not done much other than try booting it and then try booting it with a kernel i've built from upstream. > The 15% is high, is it before or with-patch? Can't remember, I did this more to find out if the copy to/from user was going to show up in the times for hdparm. > Akira >
On 19/06/2021 12:21, Akira Tsukamoto wrote: > Optimizing copy_to_user and copy_from_user. > > I rewrote the functions in v2, heavily influenced by Garry's memcpy > function [1]. > The functions must be written in assembler to handle page faults manually > inside the function. > > With the changes, improves in the percentage usage and some performance > of network speed in UDP packets. > Only patching copy_user. Using the original memcpy. > > All results are from the same base kernel, same rootfs and same > BeagleV beta board. > > Comparison by "perf top -Ue task-clock" while running iperf3. > > --- TCP recv --- > * Before > 40.40% [kernel] [k] memcpy > 33.09% [kernel] [k] __asm_copy_to_user > * After > 50.35% [kernel] [k] memcpy > 13.76% [kernel] [k] __asm_copy_to_user > > --- TCP send --- > * Before > 19.96% [kernel] [k] memcpy > 9.84% [kernel] [k] __asm_copy_to_user > * After > 14.27% [kernel] [k] memcpy > 7.37% [kernel] [k] __asm_copy_to_user > > --- UDP send --- > * Before > 25.18% [kernel] [k] memcpy > 22.50% [kernel] [k] __asm_copy_to_user > * After > 28.90% [kernel] [k] memcpy > 9.49% [kernel] [k] __asm_copy_to_user > > --- UDP recv --- > * Before > 44.45% [kernel] [k] memcpy > 31.04% [kernel] [k] __asm_copy_to_user > * After > 55.62% [kernel] [k] memcpy > 11.22% [kernel] [k] __asm_copy_to_user > > Processing network packets require a lot of unaligned access for the packet > header, which is not able to change the design of the header format to be > aligned. > And user applications call system calls with a large buffer for send/recf() > and sendto/recvfrom() to repeat less function calls for the optimization. > > v1 -> v2: > - Added shift copy > - Separated patches for readability of changes in assembler > - Using perf results > > [1] https://lkml.org/lkml/2021/2/16/778 > > Akira Tsukamoto (5): > riscv: __asm_to/copy_from_user: delete existing code > riscv: __asm_to/copy_from_user: Adding byte copy first > riscv: __asm_to/copy_from_user: Copy until dst is aligned address > riscv: __asm_to/copy_from_user: Bulk copy while shifting misaligned > data > riscv: __asm_to/copy_from_user: Bulk copy when both src dst are > aligned > > arch/riscv/lib/uaccess.S | 181 +++++++++++++++++++++++++++++++-------- > 1 file changed, 146 insertions(+), 35 deletions(-) > I'm doing some work on allow benchmarking and testing the uaccess code. So far the initial results are: > > copy routine 1: original > test 1: copier 1: offset 0, size 8192: took 43.394000 ms, 1800.364106 MiB/sec > test 1: copier 1: offset 1, size 8191: took 343.767000 ms, 227.233746 MiB/sec > test 1: copier 1: offset 2, size 8190: took 343.727000 ms, 227.232445 MiB/sec > test 1: copier 1: offset 3, size 8189: took 343.664000 ms, 227.246350 MiB/sec > test 1: copier 1: offset 4, size 8188: took 343.751000 ms, 227.161093 MiB/sec > test 1: copier 1: offset 5, size 8187: took 343.620000 ms, 227.219941 MiB/sec > test 1: copier 1: offset 6, size 8186: took 343.540000 ms, 227.245094 MiB/sec > test 1: copier 1: offset 7, size 8185: took 343.640000 ms, 227.151213 MiB/sec > copy routine 2: new > test 1: copier 2: offset 0, size 8192: took 18.819000 ms, 4151.389553 MiB/sec > test 1: copier 2: offset 1, size 8191: took 43.770000 ms, 1784.680449 MiB/sec > test 1: copier 2: offset 2, size 8190: took 43.727000 ms, 1786.217360 MiB/sec > test 1: copier 2: offset 3, size 8189: took 43.679000 ms, 1787.961944 MiB/sec > test 1: copier 2: offset 4, size 8188: took 43.620000 ms, 1790.161693 MiB/sec > test 1: copier 2: offset 5, size 8187: took 43.577000 ms, 1791.709303 MiB/sec > test 1: copier 2: offset 6, size 8186: took 43.533000 ms, 1793.301163 MiB/sec > test 1: copier 2: offset 7, size 8185: took 43.471000 ms, 1795.639456 MiB/sec > write tests: > copy routine 1: original > test 2: copier 1: offset 0, size 8192: took 43.443000 ms, 1798.333448 MiB/sec > test 2: copier 1: offset 1, size 8191: took 344.281000 ms, 226.894494 MiB/sec > test 2: copier 1: offset 2, size 8190: took 343.788000 ms, 227.192126 MiB/sec > test 2: copier 1: offset 3, size 8189: took 343.735000 ms, 227.199412 MiB/sec > test 2: copier 1: offset 4, size 8188: took 343.695000 ms, 227.198106 MiB/sec > test 2: copier 1: offset 5, size 8187: took 343.626000 ms, 227.215974 MiB/sec > test 2: copier 1: offset 6, size 8186: took 343.597000 ms, 227.207396 MiB/sec > test 2: copier 1: offset 7, size 8185: took 343.823000 ms, 227.030312 MiB/sec > copy routine 2: new > test 2: copier 2: offset 0, size 8192: took 18.999000 ms, 4112.058529 MiB/sec > test 2: copier 2: offset 1, size 8191: took 43.897000 ms, 1779.517125 MiB/sec > test 2: copier 2: offset 2, size 8190: took 43.784000 ms, 1783.891981 MiB/sec > test 2: copier 2: offset 3, size 8189: took 43.803000 ms, 1782.900481 MiB/sec > test 2: copier 2: offset 4, size 8188: took 43.768000 ms, 1784.108322 MiB/sec > test 2: copier 2: offset 5, size 8187: took 43.739000 ms, 1785.073191 MiB/sec > test 2: copier 2: offset 6, size 8186: took 43.620000 ms, 1789.724428 MiB/sec > test 2: copier 2: offset 7, size 8185: took 43.573000 ms, 1791.436045 MiB/sec > read tests: > copy routine 1: original > test 1: copier 1: offset 0, size 16384: took 87.173000 ms, 1792.412788 MiB/sec > test 1: copier 1: offset 1, size 16383: took 689.480000 ms, 226.606230 MiB/sec > test 1: copier 1: offset 2, size 16382: took 689.251000 ms, 226.667682 MiB/sec > test 1: copier 1: offset 3, size 16381: took 689.203000 ms, 226.669631 MiB/sec > test 1: copier 1: offset 4, size 16380: took 689.385000 ms, 226.595956 MiB/sec > test 1: copier 1: offset 5, size 16379: took 689.201000 ms, 226.642614 MiB/sec > test 1: copier 1: offset 6, size 16378: took 689.158000 ms, 226.642917 MiB/sec > test 1: copier 1: offset 7, size 16377: took 689.038000 ms, 226.668548 MiB/sec > copy routine 2: new > test 1: copier 2: offset 0, size 16384: took 38.825000 ms, 4024.468770 MiB/sec > test 1: copier 2: offset 1, size 16383: took 88.706000 ms, 1761.329146 MiB/sec > test 1: copier 2: offset 2, size 16382: took 88.663000 ms, 1762.075798 MiB/sec > test 1: copier 2: offset 3, size 16381: took 88.614000 ms, 1762.942535 MiB/sec > test 1: copier 2: offset 4, size 16380: took 88.592000 ms, 1763.272677 MiB/sec > test 1: copier 2: offset 5, size 16379: took 88.518000 ms, 1764.639014 MiB/sec > test 1: copier 2: offset 6, size 16378: took 88.481000 ms, 1765.269149 MiB/sec > test 1: copier 2: offset 7, size 16377: took 88.437000 ms, 1766.039585 MiB/sec > write tests: > copy routine 1: original > test 2: copier 1: offset 0, size 16384: took 87.150000 ms, 1792.885829 MiB/sec > test 2: copier 1: offset 1, size 16383: took 689.470000 ms, 226.609516 MiB/sec > test 2: copier 1: offset 2, size 16382: took 689.242000 ms, 226.670642 MiB/sec > test 2: copier 1: offset 3, size 16381: took 689.165000 ms, 226.682129 MiB/sec > test 2: copier 1: offset 4, size 16380: took 689.697000 ms, 226.493450 MiB/sec > test 2: copier 1: offset 5, size 16379: took 689.070000 ms, 226.685701 MiB/sec > test 2: copier 1: offset 6, size 16378: took 689.018000 ms, 226.688968 MiB/sec > test 2: copier 1: offset 7, size 16377: took 689.009000 ms, 226.678088 MiB/sec > copy routine 2: new > test 2: copier 2: offset 0, size 16384: took 38.871000 ms, 4019.706208 MiB/sec > test 2: copier 2: offset 1, size 16383: took 88.732000 ms, 1760.813047 MiB/sec > test 2: copier 2: offset 2, size 16382: took 88.672000 ms, 1761.896952 MiB/sec > test 2: copier 2: offset 3, size 16381: took 88.642000 ms, 1762.385661 MiB/sec > test 2: copier 2: offset 4, size 16380: took 88.730000 ms, 1760.530294 MiB/sec > test 2: copier 2: offset 5, size 16379: took 88.670000 ms, 1761.614033 MiB/sec > test 2: copier 2: offset 6, size 16378: took 88.627000 ms, 1762.361126 MiB/sec > test 2: copier 2: offset 7, size 16377: took 88.543000 ms, 1763.925356 MiB/sec > read tests: > copy routine 1: original > test 1: copier 1: offset 0, size 32768: took 243.592000 ms, 1282.882853 MiB/sec > test 1: copier 1: offset 1, size 32767: took 1426.538000 ms, 219.055127 MiB/sec > test 1: copier 1: offset 2, size 32766: took 1426.340000 ms, 219.078850 MiB/sec > test 1: copier 1: offset 3, size 32765: took 1426.297000 ms, 219.078768 MiB/sec > test 1: copier 1: offset 4, size 32764: took 1426.069000 ms, 219.107107 MiB/sec > test 1: copier 1: offset 5, size 32763: took 1425.970000 ms, 219.115631 MiB/sec > test 1: copier 1: offset 6, size 32762: took 1425.975000 ms, 219.108175 MiB/sec > test 1: copier 1: offset 7, size 32761: took 1425.906000 ms, 219.112089 MiB/sec > copy routine 2: new > test 1: copier 2: offset 0, size 32768: took 205.966000 ms, 1517.240710 MiB/sec > test 1: copier 2: offset 1, size 32767: took 304.295000 ms, 1026.932625 MiB/sec > test 1: copier 2: offset 2, size 32766: took 304.219000 ms, 1027.157825 MiB/sec > test 1: copier 2: offset 3, size 32765: took 304.114000 ms, 1027.481108 MiB/sec > test 1: copier 2: offset 4, size 32764: took 304.102000 ms, 1027.490293 MiB/sec > test 1: copier 2: offset 5, size 32763: took 304.032000 ms, 1027.695494 MiB/sec > test 1: copier 2: offset 6, size 32762: took 304.012000 ms, 1027.731733 MiB/sec > test 1: copier 2: offset 7, size 32761: took 304.250000 ms, 1026.896443 MiB/sec > write tests: > copy routine 1: original > test 2: copier 1: offset 0, size 32768: took 269.605000 ms, 1159.103132 MiB/sec > test 2: copier 1: offset 1, size 32767: took 1438.271000 ms, 217.268139 MiB/sec > test 2: copier 1: offset 2, size 32766: took 1438.197000 ms, 217.272687 MiB/sec > test 2: copier 1: offset 3, size 32765: took 1438.157000 ms, 217.272099 MiB/sec > test 2: copier 1: offset 4, size 32764: took 1438.121000 ms, 217.270906 MiB/sec > test 2: copier 1: offset 5, size 32763: took 1438.085000 ms, 217.269714 MiB/sec > test 2: copier 1: offset 6, size 32762: took 1438.012000 ms, 217.274111 MiB/sec > test 2: copier 1: offset 7, size 32761: took 1437.998000 ms, 217.269595 MiB/sec > copy routine 2: new > test 2: copier 2: offset 0, size 32768: took 237.597000 ms, 1315.252297 MiB/sec > test 2: copier 2: offset 1, size 32767: took 340.638000 ms, 917.368183 MiB/sec > test 2: copier 2: offset 2, size 32766: took 340.669000 ms, 917.256711 MiB/sec > test 2: copier 2: offset 3, size 32765: took 340.615000 ms, 917.374131 MiB/sec > test 2: copier 2: offset 4, size 32764: took 340.542000 ms, 917.542779 MiB/sec > test 2: copier 2: offset 5, size 32763: took 340.543000 ms, 917.512080 MiB/sec > test 2: copier 2: offset 6, size 32762: took 340.775000 ms, 916.859451 MiB/sec > test 2: copier 2: offset 7, size 32761: took 343.885000 ms, 908.539898 MiB/sec It looks like the aligned is about 2.2 faster on the aligned and 7.8 times faster for the unalgined tests. I'll try and get this published some time this week.