[参考译文] AM6442：memcpy 影响实时性能

很高兴知道如何确定中断延迟抖动的来源。 他们在使用什么 lib.c？ TI SDK 和 GCC 附带的 glib.c？

虽然 memcpy()通常针对吞吐量进行了极高的优化(如 https://github.com/ARM-software/optimized-routines/blob/master/string/aarch64/memcpy-advsimd.S ),但它不应直接禁用中断。 相反、它应该使用矢量端(被称为 neon 的 alsu)并调用写入流(停止进行写入分配、在 L2高速缓存中执行写入)、以获得最大吞吐量。 读取端仍将在 L2缓存中分配。 所有这一切不应该出现在十多个或更多的缓存缺失会影响循环测试的情况下、但值得深入研究使用的准确 lib.c、也许我们还提供了一个具有严重中断延迟问题的版本。

还有许多其他类似的紧密循环,如 memset()等,任意用户空间代码可以调用,因此用 dma 替换 memcpy()可能只是部分解决方案。

 Pekka

Pekka、

它来自 SDK rootfs、  

GCC-ARM-9.2-2019.12-x86_64-aarch64-none-linux-GNU 

root@am64xx-evm:/# find ./-name libc.SO.6
/lib/libc.so.6

它是使用 NEON 而不是 CPU while 循环吗？ 它不应影响中断延迟？

qi yu1 说：

是不是使用 NEON 而不是 CPU while 循环？ 它不应影响中断延迟？

是的,Arm 优化库将在一般情况下,特别是在 memcpy()上使用优化例程。 下面是两种查找 glibc 版本的方法：

root@am64xx-evm:~# ldd --version                  
ldd (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.30
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
root@am64xx-evm:~# /lib/libc.so.6
GNU C Library (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) stable release version 2.30.
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 9.2.1 20191025.
libc ABIs: UNIQUE ABSOLUTE
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
root@am64xx-evm:~# 

中断延迟不应该有大于100us 的直接影响、而是通过缓存跟踪几微秒(DDR 刷新、缓存未命中...)间接影响。 糟糕的事情。 需要通过某种间接方法来实现100us 级调度。

 Pekka

Pekka、

感谢大家的详细介绍、如何使用中断阈值重新编译 libc？ 是否有构建选项-i n (例如 DSP 编译器)？ 对 ARM 和 Linux 系统来说有意义吗？

C6000 DSP 具有外露的流水线 VLIW、这会在最严格的循环中导致中断禁用。 ARM 架构和大多数 RISC 架构不存在这个问题。 在 Arm 上的优化循环中、编译器通常不会禁用中断。

但各种优化的影响可能会产生效果、编译和链接到不同版本的 glibc 可能值得研究。 看起来像 https://developer.arm.com/Tools%20and%20Software/GNU%20Toolchain#Technical-Specifications 、而 https://www.gnu.org/software/libc/libc.html 就是最新代码所在的位置。

 Pekka

Tony、

我做了一些更多的研究,特别是在 osadl.org 和一些实验。 特别是在多核和 Cortex A53多核上实现良好延迟的一致方法似乎是使用隔离的 CPU 内核。 因此、在 uboot 处停止并传递命令行：

optargs="isolcpus=1、nohz_full=1、rcu_nocbs=1"

将内核索引1 (即 AM64x 上的第二个代码)获取为良好的中断延迟性能(隔离式内核上<100us、非隔离式内核上>100us)。 我正在一个微型文件系统上尝试此操作、并且默认使用 stress-ng memrate 后台加载(将只在内核索引0上运行)。 测试将需要一夜的时间、因此我将在此澄清是否有任何结论。

如果您尚未使用内核命令行，请访问 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1172055/faq-am625-how-to-measure-interrupt-latency-on-multicore-sitara-devices-using-cyclictest 。

我刚才添加了几个其他选项来进一步限制可以在隔离式内核上运行的功能。 我认为优化的 memcpy ()可能有某种作用,但考虑到这个用例是确定实时应用程序的优先级,例如 CoDeSys 运行时,这可能是一个有用的路径。

 Pekka

以下是使用上述操作参数、SDK 中的微型文件系统、后台加载(将在 CPU0上调度)和循环测试进行的运行：

stress-ng --memrate 1 --memrate-rd-mbs 70 --memrate-wr-mbs 140 &
cyclictest -l100000000 -n -m -Sp98 -i200 -h400 -q > output

 https://www.osadl.org/Create-a-latency-plot-from-cyclictest-hi.bash-script-for-latency-plot.0.html 中所示的带步长的绘图 

隔离式磁芯低于100us。

除了使用默认文件系统、隔离 CPU3外、AM62x 的情况相同：

显示了隔离式 CPU3中的低于50us。 因此、在这个用例中、更大的高速缓存、更高的时钟速度和更大的内核数量使得一个内核性能更佳。 该示例还显示、默认文件系统中运行的大量内容似乎会对非隔离内核造成延迟损失。

 Pekka

以下是 AM64x 8.6默认文件系统、运行时的 stress-ng memrate 在非隔离式内核中：

与上面微型文件系统的测试用例完全相同、默认情况下、隔离式内核和 bachground 内核的性能可能都差30%。

Pekka、

感谢分享、如果确定默认文件系统中的哪些内容会影响延迟结果会有所帮助、通常客户不会自行进行此类优化、如果有优化指南、也许他们会尝试。

微型文件系统太简单、不便于参考。

我们将把跟踪功能添加到 RT Linux 性能指南中。

但一般来说,为了追逐延迟客户不应该开始使用默认 SD 卡映像。 如果中断延迟是主要目标、该过程必须采用所需的最少服务并添加所需的内容。 默认文件系统不以最佳中断延迟为目标。

osadl.org 构建是一个很好的示例、说明了如果中断延迟是主要目标、应如何运行。

 Pekka