Linux中无“硬件耗时记录”标准功能，实际指通过ftrace（抓取block/irq等tracepoint）、perf（采样cycles/cache-misses等事件）和dmesg（查看启动阶段设备延迟）组合实现对磁盘I/O、中断、PCI设备等硬件操作时间开销的可观测性采集。
什么是硬件耗时记录
Linux 中没有叫“硬件耗时记录”的标准功能或配置项。用户常指的其实是：对硬件操作（如磁盘 I/O、PCI 设备响应、中断延迟）的**时间开销进行可观测性采集**，常见于性能调优、故障排查或实时性要求高的场景（如工业控制、音视频低延迟处理）。这类记录不是靠一个开关打开，而是依赖内核机制 + 工具链组合实现。
用 ftrace 抓取设备驱动级耗时
ftrace 是内核自带的轻量级跟踪器，能精确到函数级执行时间，适合分析驱动内部耗时路径。关键点在于启用对应子系统 tracepoint，而非泛泛开启所有事件。
- 确认内核已启用
ftrace支持：cat /proc/sys/kernel/ftrace_enabled应为1 - 只启用与硬件相关的 tracepoints，避免性能干扰：
echo 1 > /sys/kernel/debug/tracing/events/block/block_rq_issue/enable（记录块设备请求下发耗时） - 启用中断相关 trace：
echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable - 抓取 5 秒后停用并导出：
echo 0 > /sys/kernel/debug/tracing/tracing_on && cat /sys/kernel/debug/tracing/trace > /tmp/hw_trace.log
注意：/sys/kernel/debug 需要挂载 debugfs；普通用户需 root 权限；长时间全量 trace 会显著拖慢系统，务必按需启用子集。
用 perf record 捕获硬件事件周期
perf 更适合量化硬件事件（如 cache miss、branch mispredict、cycles）与具体指令/函数的关联，但需注意它不直接记录“耗时”，而是通过采样反推热点路径。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 记录 CPU 周期和缓存未命中：
perf record -e cycles,instructions,cache-misses -g -a sleep 10 - 聚焦磁盘 I/O 路径：
perf record -e block:block_rq_issue,block:block_rq_complete -a sleep 10 - 生成火焰图分析：
perf script | stackcollapse-perf.pl | flamegraph.pl > hw_flame.svg
常见坑：perf 默认采样频率受 /proc/sys/kernel/perf_event_paranoid 限制（值为 2 时禁止非 root 用户采集 kernel 符号），需设为 -1 或 0 才能获取完整调用栈。
用 dmesg + 时间戳看初始化阶段硬件延迟
系统启动时的硬件枚举、probe、初始化耗时，会直接打在内核日志里，这是最易获取的“硬件耗时”原始数据。
- 查看带毫秒级时间戳的启动日志：
dmesg -T | grep -i "pci\|nvme\|ata\|usb" - 定位某设备从 probe 到 ready 的时间差：
dmesg -T | awk '/nvme.*probe/ || /nvme.*ready/ {print}' - 过滤高延迟警告：
dmesg | grep -i "slow\|timeout\|stuck"
注意：dmesg -T 使用本地时钟，若系统刚启动 NTP 尚未同步，时间可能不准；生产环境建议用 journalctl -k --since "2026-07-09 18:00:00" 替代，避免日志环形缓冲区覆盖。
真正难的是把“硬件耗时”映射到业务影响——比如一次 NVMe 请求花了 20ms，是设备问题、队列深度不足，还是上层应用发了超大 IO？得结合 iostat -x 1 的 await 和 svctm、perf 的 block trace、以及驱动日志交叉验证。单点工具给不出结论。
