[参考译文] SK-AM64B：A53和 R5性能更新之间的 RPmsg、续

Chris、您好！

听起来不错。 我可能不是负责多内核调度线程的合适团队成员、但我很乐意遵循该线程来向您学习。

我将在明天或第二天尝试运行一些测试、并在有任何值得分享的内容时立即更新该线程！

此致、

Nick

部分更新：我更新了代码以测量平均延迟和最坏情况下的延迟、并在 ti-rpmsg-char 上进行了验证。 在此处更新了代码和其他详细信息：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1410313/am6442-communication-latency-issues-between-a53-and-r5-in-a-linux-rt-system/5434861#5434861

我几乎已经完成了将更新后的代码应用到零复制示例的过程、接下来我将在该示例中运行测试。

此致、

Nick

ping 该线程以使其保持活动状态。

我仍然想完成对零复制的计时测试、然后看看我是否可以为通知机制实施和测试一些内存轮询代码、而不是 RPMsg。 但是、由于目前对 Yall 的短期需求并不是如此、因此我在过去几周一直在努力控制其他主要客户请求。 希望在未来几周内重新开始这项工作。

此致、

Nick

Chris、您好！

亚历克斯告诉我,我在回过头来看看这个,所以我也会花时间完成那些零备份基准测试,我正在研究. 只是为了设定时间表预期、我本周可能不会有任何重大更新、因为这是工作日的结束、而周二是我本周工作的唯一一天。 但是、下周我会有更多更新。

你是否在你方面取得了我应该知道的任何有趣的进展、以便我们不会重复工作？

请随时将您的测试代码发送给 Alex、以便我进行查看。

此致、

Nick

Chris、您好！

最后有足够的时间来完成测试代码的编写、以查看零复制示例中使用时间的位置。 测试代码仍然存在一些问题-我在较长的运行时间内遇到分段错误、不确定是否有一些变量溢出到某个位置。 出于某种原因、这些数字也变得有点混淆了。 但是、这足以让您了解对往返延迟的贡献最大的因素。

大多数延迟是由于：
Linux 将数据写入缓冲区(1MB 为~7.1ms)
从缓冲区中读取 Linux 数据(对于1MB 为~52ms)
Linux>R5F RPMsg + R5F 读/写+ R5F>Linux RPMsg (1MB 为~12.5ms)

通常、读取前后的同步命令似乎需要小于10 μ s、因此相对于读取和写入可忽略不计。

我将推迟发布测试代码和直方图、看看我是否有更多时间来调试正在发生的情况。 但这里有一个代表性的输出：

./rpmsg_char_zerocopy -r 2 -e carveout_ipc-memories@a5000000 -t 0x01010101 -n 50
Created endpt device rpmsg-char-2-2009, fd = 4 port = 1025
Exchanging 50 messages with rpmsg device on rproc id 2 ...

dma-buf address: 0xa5000000
root@am64xx-evm:~/241206_zerocopy_test#
Completed 50 buffer updates successfully on rpmsg-char-2-2009

Buffer size = 1048576 bytes = 1024 kbytes
Pattern = 0x01010101
Total execution time for the test: 3 seconds
Many different latencies were measured in this test.

latency = Linux>R5F RPMsg + R5F read/write + R5F>Linux RPMsg.
Average latency: 12432
Worst-case latency: 13805
Histogram data at latency_histogram.txt

sync1 = Linux time to sync dmabuf before writing.
Average sync1: 1
Worst-case sync1: 8
Histogram data at sync1_histogram.txt

buffer_write = Linux time to write dmabuf.
Average buffer_write: 7129
Worst-case buffer_write: 7558
Histogram data at buffer_write_histogram.txt

sync2 = Linux time to sync dmabuf after writing.
Average sync2: 1
Worst-case sync2: 6
Histogram data at sync2_histogram.txt

sync3 = Linux time to sync dmabuf before reading.
Average sync3: 2
Worst-case sync3: 12
Histogram data at sync3_histogram.txt

buffer_read = Linux time to read dmabuf *IN MSEC*.
Average buffer_read: 52
Worst-case buffer_read: 62
Histogram data at buffer_read_histogram.txt

// sync4 output is WRONG, avg = 2, worst-case 10
// see further below
// for some reason an extra two 19057 got added on top of
// the 50 valid measurements
sync4 = Linux time to sync dmabuf after reading.
Average sync4: 764
Worst-case sync4: 19057
Histogram data at sync4_histogram.txt

Number of iterations should = 50
latency iterations = 49
sync1 iterations = 50
buffer_write iterations = 50
sync2 iterations = 50
sync3 iterations = 50
buffer_read iterations = 48
sync4 iterations = 52
TEST STATUS: PASSED

# vi sync4_histogram.txt
// all 50 measurements are <= 10usec
0 , 0
1 , 28
2 , 12
3 , 2
4 , 0
5 , 4
6 , 1
7 , 0
8 , 2
9 , 0
10 , 1

此致、

Nick

其中、这是"写入数据"测量的对象

void buffer_init
...
        for(i = 0; i < lbuf->size / sizeof(uint32_t); i++)
                lbuf->shared_buf[i] = pattern;

这是 "读取数据"测量值

int buffer_validate
...
for(i = 0; i < len; i++) {
                if (lbuf->shared_buf[i] != pattern)
                        break;
        }