工具与软件:
我只读了 https://lwn.net/Articles/969062/ 和 https://lwn.net/Articles/925371/上的 Linux 6.6 (在 Linux SDK V10中) EEVDF 信息 、可以 参考 AM64x Academy (即基准测试、样片调度应用程序)来利用 EEVDF、可以获得哪些实用信息? 这是否会影响两个 A53内核之间的 SMP 功能? 请向 NICK/BIN/Pratheesh/Vignesh/Nishanth 寻求反馈
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具与软件:
我只读了 https://lwn.net/Articles/969062/ 和 https://lwn.net/Articles/925371/上的 Linux 6.6 (在 Linux SDK V10中) EEVDF 信息 、可以 参考 AM64x Academy (即基准测试、样片调度应用程序)来利用 EEVDF、可以获得哪些实用信息? 这是否会影响两个 A53内核之间的 SMP 功能? 请向 NICK/BIN/Pratheesh/Vignesh/Nishanth 寻求反馈
Jim、您好!
您有具体问题吗?
听起来 EEVDF 调度程序在开发过程中仍然很早。 我怀疑 TI 对"常规"Linux (似乎是该调度程序的目标)的基准测试将继续使用标准调度程序、但我可以根据需要提出问题。
目前,如果你有特定的进程,你想在特定的时间内完成,我建议使用 RT Linux 代替普通的 Linux,以便你可以设置适当的优先级。 请注意、RT Linux 不是真正的 RTOS、因此您始终有可能获得超出所需窗口的延迟。 如果偶尔更长的延迟会破坏您的设计、我们不建议使用 RT Linux。
有关您可以在(非优化) RT Linux 上预期的行为类型的示例、请查看我在 SDK 10.0上运行的最新 IPC 基准测试。 我发现直方图特别有趣。
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1388960/sk-am64b-rpmsg-between-a53-and-r5-performance-update/5328241#5328241
有关为时间关键型控制路径选择操作系统的更多讨论、请参阅
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1085663/faq-sitara-multicore-system-design-how-to-ensure-computations-occur-within-a-set-cycle-time
此致、
Nick
尼克:
根据 https://kernelnewbies.org/Linux_6.6、 EEVDF 似乎已经过测试、并于去年被插入到 Linux 6.6基准中; 有 我想请您 确认 EEVDF 确实取代了"完全公平调度"(CFS )?
如果是、我想知道调度程序的接口是否在6.1. 和6.6
查看您为另一位客户运行的那些基准测试、在了解了有关 EEVDF 的信息后、我怀疑 EEVDF (某种形式的)位于 SDK v10中的 TI RT-Linux v6.6构建版中。
同时,我从 https://elixir.bootlin.com/linux/v6.6.32/source/kernel/sched/core.c 做了一个快照 .
然后我跑了2个扩散器(连接)与路径上的一个
.../ti-processor-sdk-linux-rt-am64xx-EVM-10.00.07.04/board-support/ti-linux-kernel-6.6.6.32+git-ti-rt/kernel/sched/core.c
报告:
e2e.ti.com/.../diffz.txte2e.ti.com/.../diffy.txt
重定向的2个报告的区别是以下来自我的 Linux 终端。
jmrowca@jm-Kabylake-Client-platform:~/Downloads$ diff -y -W 132 core.c linux_6_6_32-kernel-sched-coreDOTc.c > diffy.txt
jmrowca@jm-Kabylake-Client-platform:~/Downloads$ diff -y -W 132 --suppress-common-lines core.c linux_6_6_32-kernel-sched-coreDOTc.c > diffz.txt
尽管我意识到 TI 使用 C 源代码定制了用于 Sitara 处理器的 Linux 实现、但我确实 向 TI Linux 驱动程序作者提出了两个问题:
1>是否在 TI RT 实现中擦除了所有"void rt_mutex_*" Linux 内核 C 源代码? (参见 diffz.txt 文件中的第76:92行)
2> 是否已在 TI RT 实现中擦除所有"void resched_*" Linux 内核 C 源代码("void resched_CURR"除外)? (参见 diffz.txt 文件中的第22:44行)
Nick 对于 TI Linux RT 选择也是一个不错的选择;我的首次应用在一种类型的刚性容器检测系统上具有不同的关键计时路径、因此我需要对直接的 Linux 和 RT 进行评估。
谢谢 Jim
Jim、您好!
首先、设置一些预期-听起来您正在相当深入地自定义调度程序代码。 此时、您超出了我们在论坛上可以支持的范围、而更多地进入了"一般 Linux"问题领域。
我们的开发人员在内核6.6版本中没有使用 EEVDF 调度程序执行任何操作。 是的、它存在于 Linux 代码中、但我们不使用它。
RT Linux 用户不熟悉从代码库中具体删除 RT_mutex_*或重新调度_*代码。 如果不深入研究、我的想法可能只是在这些特定实例中、TI 代码库"自然而然地"与主线分散、而不是专门删除主线内核中存在的内容。
此致、
Nick