绝大部分时候是可以的

busy polling 有个问题

1 如果你的进程不是实时RT的，那总会有一个默认50us的时间差
2 如果你的进程不是实时RT最高优先级的（RT99），那可能会被调度出CPU；
3 即使你的进程是实时最高优先级的，进程还是可能被调度出CPU，因为/proc/sys/kernel/sched_rt_period_us 保证你只能用到95% 的CPU时间；
4 即使你的进程是实时最高优先级的，/proc/sys/kernel/sched_rt_period_us 也设置为100%，你会发现你的进程还是被系统中断了（LOC中断，TLB中断）；
5 即使你的进程是实时最高优先级的，/proc/sys/kernel/sched_rt_period_us 也设置为100%，还想办法屏蔽了中断，你会发现你的进程还是不断的被NMI中断；
6 即使你的进程是实时最高优先级的，/proc/sys/kernel/sched_rt_period_us 也设置为100%，还想办法屏蔽了中断，关闭了NMI watchdog，你发现进程还是有抖动，来自于操作系统以下的硬件问题；

并且在你屏蔽某个核心的中断过程中，你机器宕机了，因为其他核心发起的IPI中断被你的busy polling阻塞而导致整个机器无法响应了。


【 在 chunhui 的大作中提到: 】
: 能否大致估算一下，那种疯狂轮询的方法能不能达到1ms的要求？
--
FROM 111.181.47.*