唯一可靠方式是cat /sys/block/设备名/queue/scheduler，输出如noop [mq-deadline] kyber bfq，方括号内为当前生效项；nvme设备常见[none]属正常绕过调度层，无需修改。
怎么确认当前设备支持哪些调度器并看到生效项
直接看 /sys/block/设备名/queue/scheduler 是唯一可靠方式，其他命令（如 lsblk、df）不暴露调度器信息。先用 lsblk -d 或 cat /proc/partitions 确认物理设备名（排除 loop、dm-、zram），再查对应路径：
-
cat /sys/block/sda/queue/scheduler输出形如noop [mq-deadline] kyber bfq，方括号内是当前激活项 -
cat /sys/block/nvme0n1/queue/scheduler常见输出为mq-deadline kyber [none]——这不是错误，而是 NVMe 设备主动绕过软件调度层 - 若看到
[none]且设备确实是 NVMe（不是伪装成 NVMe 的 SATA SSD），就不用强行改；若 SATA SSD 显示[cfq]或[deadline]，才值得切换
临时改成 none 或 mq-deadline 的实操要点
写入 /sys/block/设备名/queue/scheduler 立即生效，但重启丢失。关键限制和风险比想象中多：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 必须用 root 权限：
echo none | sudo tee /sys/block/nvme0n1/queue/scheduler（NVMe）或echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler（SATA SSD/HDD） - 只能写入
cat输出中列出的名称，写cfq到只显示mq-deadline kyber [none]的设备会报Invalid argument - NVMe 设备写
none实际映射为内核跳过调度层，但写mq-deadline可能被拒绝（取决于驱动和内核版本），写完仍显示[none]就说明没生效 - 对根设备（如装系统的
sda）反复切换可能触发IO scheduler not changed due to active requests警告，短暂卡顿不可避免
永久生效：GRUB 参数 vs udev 规则怎么选
靠 elevator=xxx 写进 GRUB 启动参数是最通用的方式，但无法区分设备类型；udev 更灵活，适合混用 NVMe + SATA SSD + HDD 的场景：
- GRUB 方式：编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX_DEFAULT行末加空格分隔的elevator=none或elevator=mq-deadline，然后运行sudo update-grub（Debian/Ubuntu）或sudo grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL/CentOS） - udev 方式（推荐多盘差异化）：新建
/etc/udev/rules.d/60-io-scheduler.rules，内容如：ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="mq-deadline"
之后执行sudo udevadm control --reload-rules && sudo udevadm trigger --subsystem-match=block - 别用
/etc/rc.local：设备名在启动早期常未就绪，脚本静默失败
为什么 none 不等于“更快”，mq-deadline 也不是万能解药
调度器效果高度依赖硬件能力与负载特征，盲目切换反而抬高延迟：
-
none把所有调度权交给设备固件——廉价 SATA SSD 固件缺陷多，开none可能导致请求乱序、GC 压力暴增；云盘（如 AWS EBS）底层已做调度，开none才合理 -
mq-deadline在 HDD 上通过 LBA 排序显著降寻道，在数据库随机读写中比noop低 10%~15% 的 99 分位延迟，但它默认读超时 500ms、写超时 5s，调参需谨慎：读超时设太短（如 100ms）会频繁提前派发，增加驱动压力；写超时设太长（如 30s）会让大日志刷盘阻塞其他请求 - 内核版本决定可用性：5.0+ 内核才稳定支持
mq-deadline；CentOS 7 默认 3.10 内核只能用单队列deadline，硬写mq-deadline会失败
