renice是唯一能修改已运行进程nice值的命令，因其直接调用setpriority()系统调用更新内核task_struct中的static_prio和vruntime，而nice仅作用于进程启动阶段。
直接用 renice，不是 nice —— 后者只管启动新进程，对已运行的进程完全无效。
为什么 renice 是唯一靠谱的选择
因为 nice 只在 fork() + exec() 阶段起作用，进程一旦跑起来，它的调度上下文就固定了。renice 才是专为运行中进程设计的系统调用封装，它直接调用 setpriority() 修改内核中的 task_struct->static_prio 和 vruntime 偏移量。
-
renice 5 1234表示把 PID 1234 的 nice 值设为绝对值 5（不是“加 5”） - 想相对调整？得写成
renice +3 1234或renice -2 1234，但必须加符号，否则默认按绝对值处理 - 不带
-n也能用，但显式写renice -n 10 -p 1234更安全，避免旧版工具解析歧义
renice 权限和范围限制必须提前确认
普通用户只能调高自己进程的 nice 值（即让优先级更低），且不能低于 0；root 才能设负值或改别人进程。权限不足时会报错：setpriority: Permission denied。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查自己能动哪些进程：
ps -u $USER -o pid,ni,comm - 确认目标进程归属：
ps -o pid,user,comm -p 1234，如果 user 不是当前用户，非 root 就别试了 - 想批量调低某用户所有进程：
renice +5 -u alice，但同样受限于权限边界 - 容器内进程通常无法被宿主机
renice生效——cgroup v2 默认隔离了cpu.weight，得进容器或用docker update --cpu-shares
怎么验证 renice 真生效了
top 默认不显示 NI 列，很多人以为没改成功，其实是看漏了。另外 systemd 服务可能在启动时覆盖你设的值。
- 立刻验证命令：
ps -o pid,ni,comm -p 1234，输出第三列就是当前 nice 值 - 在
top中按f→ 选中NI→ 按空格启用 → 按q退出，NI 列才会出现 - 查 systemd 服务原始设置：
systemctl show nginx | grep Nice，如果返回Nice=5，说明它启动时自带值，你renice后可能被下一次 reload 覆盖 - 注意：
PR（priority）列 =20 + NI，所以 NI=10 对应 PR=30，别拿 PR 值反推错了
renice 不是万能的，CPU 之外的瓶颈它压不住
如果你发现一个进程 CPU 占用不高但系统卡顿，renice 基本没用——它只影响 CFS 调度器对 CPU 时间片的分配逻辑，对 I/O、内存、锁竞争完全无感。
- 磁盘狂刷？得用
ionice -c 3 -p 1234把它丢进 idle I/O class - 内存疯涨？
renice不阻止 OOM killer，得靠 cgroups 限memory.max - 想真正稳住系统负载，得组合用：
renice管 CPU、ionice管 I/O、cgexec管内存/CPU 配额
