ionice不能提供IO带宽保障，仅影响时间片分配机会；需用cgroups v2的io.max配合BFQ调度器实现读写带宽硬限速，并结合chrt和taskset保障CPU资源。
Linux 中没有 ioprio-r 这个命令或内核机制。你提到的可能是对 ioprio_set（或其用户态封装工具 ionice）的误写，或是将实时调度（SCHED_FIFO）、IO优先级（ioprio）与带宽保障目标混淆了。
IO优先级 ≠ IO带宽保障
ionice 设置的是进程的 IO 调度优先级（class + level），影响的是它在块层（如 CFQ、mq-deadline、BFQ）中获取磁盘时间片的“机会大小”，但不保证最小带宽、不设上限、也不隔离资源。即使把流媒体进程设为最高 IO 优先级（ionice -c 1 -n 0），当系统出现大量高优先级 IO 请求（如数据库刷盘、日志同步）时，它仍可能被延迟或饿死——这无法满足实时流媒体对稳定 IO 延迟和可预测吞吐的要求。
真正能提供 IO 带宽保障的机制
要实现“保障”，需依赖内核的IO 控制组（IO cgroup v2）+ BFQ 或 mq-deadline 调度器，配合 io.max 和 io.weight 接口：
-
确认内核支持：运行
cat /proc/filesystems | grep cgroup确保已挂载 io cgroup v2（通常挂载在/sys/fs/cgroup/io）；检查调度器：cat /sys/block/nvme0n1/queue/scheduler（推荐 BFQ，尤其对 NVMe/SSD） -
创建专用 cgroup：
sudo mkdir -p /sys/fs/cgroup/io/streamer -
限制最小带宽（保障）：
echo "nvme0n1 rbps=50000000" | sudo tee /sys/fs/cgroup/io/streamer/io.max（保障 50MB/s 读带宽） -
限制最大带宽（防干扰）：
echo "nvme0n1 wbps=30000000" | sudo tee /sys/fs/cgroup/io/streamer/io.max（限制写带宽上限） -
将进程加入该组：
echo $PID | sudo tee /sys/fs/cgroup/io/streamer/cgroup.procs（启动前或运行中均可）
配合实时调度提升端到端确定性
仅靠 IO 隔离还不够。流媒体处理还需 CPU 时间保障：
- 用
chrt -f 50 ./streamer启动进程，赋予 SCHED_FIFO 实时调度策略 - 绑定到独占 CPU 核：
taskset -c 4,5 ./streamer，避免调度抖动 - 关闭该 CPU 核的中断平衡：
echo 0 | sudo tee /proc/irq/*/smp_affinity_list（按需） - 禁用 CPU 频率缩放：
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
为什么不推荐 ionice 单独使用？
ionice 在以下场景会失效：
- 所有进程都设为
ionice -c 1（实时类），则完全退化为 FIFO，无优先级区分 - 使用 noop 或 none 调度器（常见于 NVMe）时，ionice 被忽略
- Direct I/O 绕过 Page Cache，部分调度器对其权重调整效果减弱
- 无法防止其他进程耗尽内存导致 swap I/O 暴增，间接冲击流媒体 IO 延迟
IO cgroup v2 + BFQ 是当前 Linux 中唯一能提供可配置、可验证、内核级 IO 带宽保障的方案。ionice 仅适合轻量级优先级提示，不能替代资源隔离。
