net: netlat: interpret the ack sysctl threshold in milliseconds · Pull Request !1299 · OpenCloudOS/OpenCloudOS-Kernel

## 问题

`netlat_ack_check()` 把 `net.ipv4.netlat.ack` 的原始 sysctl 值直接与 `tcp_jiffies32_delt()` 返回的 **jiffies** 时延做比较,而同文件的 `netlat_queue_check()` / `netlat_pick_check()` 都是拿 sysctl 值与 `ktime_to_ms()` 的 **毫秒** 时延比较。

已合入主干的 `Documentation/networking/netlat.rst`(commit 7aa9dd7738cc6)把三个旋钮都写成 `int (ms)`,并给出示例:"a 10 ms ack threshold: `echo 10 > /proc/sys/net/ipv4/netlat/ack`"。代码与已合入文档在 ack 旋钮单位上相互矛盾。

## 影响

- x86 defconfig 选 `HZ_1000`,1 jiffy == 1 ms,数值上恰好一致,所以不可见;
- 本仓 arm64 defconfig 未选 HZ,按 `kernel/Kconfig.hz` 的 `default HZ_250` 落在 **HZ=250**:文档写 10 ms,实际阈值是 10 jiffies = **40 ms**,10–40 ms 之间应记录的 ack 时延被静默漏记;HZ=100 时漏记窗口扩大到 100 ms;
- `TCP AC` 输出行打印的是 `jiffies_to_msecs(lat)`(毫秒),与 queue/pick 一致,进一步说明毫秒才是对外的统一契约。

## 修复

比较前用 `msecs_to_jiffies()` 转换 sysctl 值,最小一行改动:

```c
-	thresh = get_ack_lat(net);
+	thresh = msecs_to_jiffies(get_ack_lat(net));
```

- `msecs_to_jiffies(0)` 为 0,写 0 仍然关闭 ack 测量;
- HZ=1000 时转换是恒等,现有 x86 部署行为不变(向后兼容)。

## 验证

独立红绿模型(复刻 v6.6 `jiffies_to_msecs()`/`msecs_to_jiffies()` 精确算法与 netlat_ack_check 判定逻辑):

- 红:HZ=250、`echo 10 > ack`、真实时延 32 ms(8 jiffies)——旧码 8<10 不记录,违反文档;修后 `msecs_to_jiffies(10)=3`,8>=3 记录。HZ=100(50 ms 不记录)、HZ=300 同样复现;
- 绿:修复后对 HZ∈{100,250,300,1000} 全量扫描 ack=1..50 × 时延=0..50,判定与文档毫秒契约一致(jiffies 粒度内);低于阈值无误报,写 0 语义保持;
- 向后兼容:HZ=1000 下 ack=1..20 × 时延=0..20 全对,修复前后判定表完全相同;
- checkpatch.pl:0 errors, 0 warnings。

无真实流量机器,运行时行为依据上述代码路径与模型论证。

Fixes: dcaebf61e6e95 ("net/netlat: add a tcp latency watcher")

类型	指派人员	状态
审查	zoucao Huang Cun Jianping Liu	已完成 (0/0人)
测试	Jianping Liu	已完成 (0/0人)

GVPOpenCloudOS / OpenCloudOS-Kernel

搜索帮助

GVP OpenCloudOS / OpenCloudOS-Kernel