ARM处理器中的Linux max_cstates和空闲引导选项

时间:2015-08-25 14:03:59

标签: linux-kernel arm real-time intel

最近,当我们从Intel Core2 Duo(2核)更改平台时:

[environment]

到英特尔酷睿i5(4核):

Kontron Embedded Computers KISS PCI-760 2U
SMP 2x Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz 3000MHz (6144KB cache) 3883 MB memory 

这些系统使用RT_PREEMPT补丁运行Scientific Linux CERN版本6.6:

Kontron AG KISS PCI-762 2U
Intel(R) Core(TM) i5-3550S CPU @ 3.00GHz 2993MHz (6144KB cache) 3838 MB memory 

在更改之后,我们观察到中断延迟从大约10us降低到超过100us,异常值高达1ms。使用专用硬件测量中断延迟的时间精度为1us。

我们非常肯定这些测量结果,事实上,这些测量结果也同意在~1us级别(使用外部硬件)两个同步设备之间发送和接收数据包之间的延迟时间的降低。 / p>

通过更改为Scientific Linux 6.6上的以下Linux启动选项,问题得以解决(返回到〜10us延迟的相同基线):

Scientific Linux CERN SLC release 6.6 (Carbon)
Linux 3.6.11-rt30.25.el6rt.x86_64 x86_64

您可以在https://access.redhat.com/articles/65410

找到解释

问题是:上述参数在ARM处理器上是否有效?我在哪里可以找到一些文档?

修改

考虑@Notlikethat评论,我使用cyclictest测量了延迟。在使用SLC 6.6和RT_PREEMPT补丁(以及上面的cstate和idle选项)的i5和Intel Code Duo2处理器上,使用4个内核时,最大延迟为16us。此测量与使用专用硬件执行的测量一致。

在ARM Cortex A7上运行Linux报警4.0.8-3-rt6-ARCH时,我的最大延迟为136us。

请注意,英特尔酷睿2和i5都有类似的延迟,而ARM Cortex A7则有10倍。

我的问题是:

  • Linux下的ARM处理器是否需要调整以改善延迟(除了将/ dev / cpu_dma_latency设置为0us之外)?
  • 差异来自哪里?

谢谢,

0 个答案:

没有答案