BFQ 스케줄러를 활성화하고 사용하는 방법은 무엇입니까?

방금 ukuu (Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility )를 사용하여 Ubuntu 17.04에 Linux 커널 버전 4.12를 설치했습니다 .

문제는 사용 가능한 I / O 스케줄러를 확인할 때 BFQ 또는 Kyber I / O 스케줄러를 찾을 수없는 것입니다.

cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]

그렇다면이 Linux 버전에서 새로운 스케줄러 중 하나를 사용하는 방법은 무엇입니까?

linux-kernel scheduling

— 시암
소스

나는 우분투에 없지만 Fedora에서 내가 한 일이 도움이 될 수 있습니다.

BFQ는 blk-mq (Multi-Queue Block IO Queuing Mechanism) 스케줄러이므로 부팅시 blk-mq를 활성화하고 / etc / default / grub 파일을 편집하고에 추가 scsi_mod.use_blk_mq=1해야합니다 GRUB_CMDLINE_LINUX. 이것은 grub 파일입니다. 예를 들면 :

GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=false
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="quiet vt.global_cursor_default=0 scsi_mod.use_blk_mq=1"
GRUB_DISABLE_RECOVERY="true"

그 후에는 grub을 업데이트해야합니다. Fedora 에서는 부팅 방법에sudo grub2-mkconfig -o /path/to/grub.cfg 따라 다른 것을 사용해야 합니다. 우분투에서는 간단히 다음을 실행할 수 있습니다.

sudo update-grub

재부팅하면 다음이 나타납니다.

cat /sys/block/sda/queue/scheduler
[mq-deadline] none

아마도 커널은 BFQ로 모듈 로 컴파일 되었으므로 Kyber의 경우도 마찬가지입니다.

sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none

를 /etc/modules-load.d/bfq.conf포함 하는 파일 을 추가하여 부팅시 추가 할 수 있습니다 bfq.

blk_mq를 활성화하면 blk_mq가 아닌 스케줄러를 사용할 수 없으므로 noop cfq 및 nonmq 마감일을 잃게됩니다.

분명히 blk_mq 스케줄링 시스템은 grub에서 엘리베이터 플래그를 지원하지 않으며,보다 세밀한 제어를 제공하는 보너스와 함께 udev 규칙을 대신 사용할 수 있습니다.

/etc/udev/rules.d/60-scheduler.rules존재하지 않는 경우 작성 하고 추가하십시오.

ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"

필요한 경우 여기에서 지적한 바와 같이 속성을 사용하여 udev 규칙에서 회전 (HDD) 장치와 비 회전 (SSD) 장치를 구별 할 수 있습니다 ATTR{queue/rotational}. BFQ 개발자 인 Paolo Valente는 LinuxCon Europe에서 BFQ 가 낮은 지연 시간 보증의 관점에서 스케줄러 noop또는 deadline스케줄러 보다 더 나은 선택이 될 수 있다고 지적 했습니다. 이는 SSD에도 사용하는 것이 좋습니다.

파올로의 비교 : https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be

저장하고 다시로드하고 트리거하십시오 udev rules.

sudo udevadm control --reload
sudo udevadm trigger

— 로물로
소스

난 그냥 참고하고 싶습니다 : 당신이 램 중단 할 수 있다고 기대하는 리눅스 <4.15의 컴퓨터에서는 이것을하지 마십시오; <4.15는 "안전한 SCSI Quiescing"수정 사항이 없기 때문에 이력서에 모든 IO를 정지시킵니다.

— Ivan Kozik

blk-mq를 활성화하면 일부 시스템에서 커널을로드 할 때 바로 커널에 "oops"를주는 것처럼 보이는 커널 4.14에서도 문제가있을 수 있습니다. 당신이 그것을 찾지 않으면 그것을 놓칠 수도 있지만 당신이 편집증이라면 그것은 무언가가 깨 졌다는 신호일 수 있습니다.

— CR.

약간 더 정확한 udev 규칙을 사용하는 것이 좋습니다. 여기에 표시된 것을 시도했을 때 udev는 이름이 해당 패턴과 일치하는 일부 장치에 대해 스케줄러를 설정하려고 시도했지만 BFQ 스케줄러를 사용할 수있는 SCSI 블록 장치는 아닙니다. 내가 끝내는 규칙은 다음과 같습니다. ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"장치 이름과 패턴 일치를 피하여 일치를보다 정확하게 만듭니다. "queue / scheduler"속성이 없기 때문에 파티션 장치와 일치하지 않습니다.

— Dan Molding

커널 4.15-4.16은 BFQ를 사용하는 동안 드라이브의 파티션 구성표를 업데이트하면 완전한 I / O 잠금이 발생할 수있는 매우 심각한 버그로 인해 어려움을 겪고 있습니다. 참조 : lkml.org/lkml/2017/12/1/80

— Glutanimate

훌륭한 RomuloPBenedetti 답변 을 확장하려면 :

PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'"udev 규칙 을 사용하여 특정 장치에서 bfq 스케줄러를 실제로 사용할 수 있는지 테스트 할 수 있습니다 . 이것은 효과적으로 대체 DRIVERS=="sd|sr"하고 잊어 버린 경우에만 발사되지 않습니다.scsi_mod.use_blk_mq=1

하찮은 일:

PROGRAM-일치하는 프로그램이 있는지 확인하십시오. 프로그램이 성공적으로 리턴되면 키는 true입니다. 절대 경로가 제공되지 않으면 프로그램은 / lib / udev에 있어야합니다.
$sys-sysfs 마운트 지점 ( /sys).
$devpath -장치의 경로 (/ devices / pci / ...).

— 아라 노-카이
소스