为什么rcu的grace period时间那么长?
我在调试中发现, 在系统没做什么事情的时候, 在kernel 3.10测试代码中单独调用synchronize_rcu(), 居然要花费50ms, 而每次都要这么长时间.以前3.4的版本也要花上个7,8个ms. 看了一下rcu的机制, 但是不了解gp为啥要这么长时间. 邪乎的是, 从系统boot开始, 系统也有很多次synchronize_rcu()时间超过100ms的情况. 而且从网上介绍来看gp也是要花费很多ms的.理论上说synchronize_rcu要等待所有reader 一个宽限期,但怎么会有这么长时间呢? 首先reader 获取read lock也不会很慢吧, 另外, rcu要其他cpu切换一次上下文也表示gp结束, 但最大的调度切换也就几个ms. 所以数十ms的情况是怎么来的呢?如果rcu加速了reader访问,但是对writer如此滞后生效, 是不是有问题呢?此外, grace period的周期有没有办法精确计算出来呢?
谢谢! 更为郁闷的是, 当我把cpu1-*全部offline, 只留下cpu0时, 单独测试synchronize_rcu()的时间, 居然也要花费25ms.怎么会这样呢? synchronize_rcu把自己挂起后，会不会有其他高优先级线程一直调度，导致挂起的线程长时间得不到运行呢？
把trace_rcu开上再试试？
页:
[1]