看起来你碰到了内核模块里典型的偶发延迟问题——这种0.1%的异常大概率是内核抢占搞的鬼，毕竟你的任务才微秒级，哪怕被打断几毫秒，rdtscp的计数都会跳得离谱。Linux内核默认是抢占式的，哪怕是进程上下文的模块代码，也可能被更高优先级进程、软中断甚至硬中断打断，刚好就撞上那0.1%的概率。

下面给你几个递进的解决方案，你可以根据硬件原型的实际需求选择：

1. 临时关闭本地中断（最直接的快速修复） #

如果你的计算任务完全不需要响应中断，而且确实是极短的（数微秒级），可以在任务前后用local_irq_disable()和local_irq_enable()把代码包起来：

u64 start_cycles, end_cycles;

// 关闭本地CPU的中断，防止被打断
local_irq_disable();
start_cycles = rdtscp();
ndelay(10);  // 这里替换成你的实际计算逻辑
end_cycles = rdtscp();
// 恢复中断
local_irq_enable();

// 计算耗时（记得根据CPU主频转成微秒）
u64 elapsed_us = (end_cycles - start_cycles) / (cpu_khz / 1000);

⚠️ 注意：关闭中断会影响本地CPU的中断响应，所以必须保证这段代码绝对短，不能有任何阻塞操作，否则会拖慢整个系统的中断处理。

2. 禁用内核抢占（更温和的选项） #

如果你的任务允许响应硬中断，但不想被其他进程抢占，可以用preempt_disable()和preempt_enable()：

preempt_disable();
start_cycles = rdtscp();
ndelay(10);
end_cycles = rdtscp();
preempt_enable();

这个方法只禁止内核调度器抢占当前进程，硬中断仍然可以正常处理，适合对中断延迟敏感但又不想完全屏蔽中断的场景。

3. CPU绑定+实时优先级（用户态辅助优化） #

如果你的模块是通过用户态程序触发的，可以把用户态进程绑定到固定CPU，并设置实时优先级，减少被调度到其他CPU或被低优先级进程抢占的概率：

# 把进程绑定到CPU 0运行（避免跨CPU调度的延迟）
taskset -c 0 ./your_user_space_trigger
# 设置实时优先级（需要root权限，99是最高实时优先级）
chrt -f 99 ./your_user_space_trigger

配合内核态的抢占禁用，能进一步降低异常延迟的概率。

4. NO_HZ_FULL内核特性（极致延迟优化） #

如果你的系统对延迟要求极高，可以开启CONFIG_NO_HZ_FULL内核配置，把某个CPU设置为“无滴答”模式——这样该CPU不会有周期性的时钟中断，从根源上避免了时钟中断导致的抢占。不过这个需要重新编译内核，而且可能会影响系统的一些统计功能，适合极端场景。

验证方法 #

修改代码后，建议跑足够多的测试样本（比如100万次），统计rdtscp的时间分布，看0.1%的异常延迟是否消失。另外也可以用perf工具跟踪抢占事件，确认问题根源：

# 记录内核抢占事件，生成报告
perf record -e sched:sched_stat_preempt -g ./your_test_program
perf report

内容的提问来源于stack exchange，提问作者Evan