关于 利用 timerfd 扩大时间窗的疑惑

[hac425xxx]

您好，我看您在文中提到由于 rcu 宽限期需要通过 ipi 来结束，所以无法使用 timerfd 的方式扩大时间窗

The iteration task experiences an interruption (e.g., timer interrupt), during which the RCU grace period concludes. It is possible to employ timerfd to create multiple hardware timers that, upon timeout during the VMA iteration, can trigger a lengthy interrupt. However, this approach is not viable because the interrupt handler operates with interrupts disabled, and if a CPU cannot handle inter-processor interrupts (IPIs), the RCU grace period will not end.

对此我有些疑惑，希望能得到解答：

查看了 rcu 的部分代码，发现走快速 rcu 时才会通过 synchronize_rcu_expedited 发送 ipi 要求其他 cpu 上报状态，正常rcu 的话是通过 wait_rcu_gp(call_rcu_hurry) 来等待宽限期结束。您测试的内核上是默认走 synchronize_rcu_expedited 分支吗？

[lrh2000]

我当时是通过实验验证的这件事情，具体是这样的：

1. 测试进入内核后直接死循环，另一个核上执行synchronize_rcu()，可以正常结束RCU宽限期；
2. 测试进入内核后关中断死循环，另一个核上执行synchronize_rcu()，发现RCU宽限期永远不会结束。

不过现在想来这个实验设计的并不够严谨，因为它不能排除是其他中断的影响。我试图阅读RCU的代码来理解这个现象，但发现代码十分复杂，尝试了一段时候后也没太搞懂，但是注意到了其中涉及IPI，所以做出了文中所示的表述。如果您觉得这个判断实际上不太正确的话，非常欢迎批评指正，我也可以学习一下。

[hac425xxx]

多谢回复，那也许 synchronize_rcu 里面就是走了 synchronize_rcu_expedited 这个分支，具体的我也不是很熟悉 ~~

忽然想起另一个问题，您这是通过 synchronize_rcu 等其他 CPU 回应，有没有可能 不使用 synchronize_rcu + timerfd 中断 rcu 宽限期能够过并执行 call_rcu 注册的回调函数，

[lrh2000]

我也不太清楚这个，感觉比较快的确认方法还是通过实验直接验证一下，毕竟我当时去写利用也基本上是从实验的角度观察到了一些 RCU 的行为，虽然我猜测的话 synchronize_rcu 如果导致宽限期反而不能如期结束了， 看上去是一件比较奇怪的事情

[hac425xxx]

嗯，有机会试试，多谢