Chọn một Bộ lập lịch I/O Linux

Question

Tôi đọc rằng có thể thay đổi bộ lập lịch I/O cho một thiết bị cụ thể trên hạt nhân đang chạy bằng cách ghi vào/sys/block/[disk]/queue/scheduler. Ví dụ: tôi có thể thấy trên hệ thống của mình:

anon@anon:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 

rằng mặc định là trình lập lịch xếp hàng hoàn toàn công bằng. Những gì tôi tự hỏi là nếu có bất kỳ sử dụng trong bao gồm tất cả bốn schedulers trong hạt nhân tùy chỉnh của tôi. Có vẻ như không có nhiều hơn một bộ lập lịch được biên dịch trừ khi hạt nhân đủ thông minh để chọn bộ lập lịch chính xác cho phần cứng chính xác, cụ thể là bộ lập lịch 'noop' cho các ổ đĩa flash và một trong những bộ khác cho truyền thống ổ cứng.

Đây có phải là trường hợp không?

Answer 1

Như được ghi trong /usr/src/linux/Documentation/block/switching-sched.txt, trình lên lịch I/O trên bất kỳ thiết bị khối cụ thể nào có thể được thay đổi khi chạy. Có thể có một số độ trễ vì các yêu cầu của trình lên lịch trước đều bị xóa trước khi đưa trình lên lịch mới vào sử dụng, nhưng nó có thể được thay đổi mà không gặp sự cố ngay cả khi thiết bị đang được sử dụng nhiều.

# cat /sys/block/hda/queue/scheduler 
noop deadline [cfq] 
# echo anticipatory > /sys/block/hda/queue/scheduler 
# cat /sys/block/hda/queue/scheduler 
noop [deadline] cfq 

Lý tưởng nhất, sẽ có một trình lập lịch biểu duy nhất đáp ứng mọi nhu cầu. Nó dường như chưa tồn tại. Hạt nhân thường không có đủ kiến ​​thức để chọn lên lịch tốt nhất cho khối lượng công việc của bạn:

• noop thường là sự lựa chọn tốt nhất cho các thiết bị khối bộ nhớ được hỗ trợ (ví dụ đĩa RAM) và các phương tiện truyền thông không quay (flash), nơi cố gắng sắp xếp lại I/O là một sự lãng phí nguồn lực
• deadline là một lịch trình nhẹ mà cố gắng đặt một giới hạn cứng về độ trễ
• cfq cố gắng để duy trì sự công bằng cho toàn hệ thống I/O băng thông

Mặc định là anticipatory trong một thời gian dài và đã nhận được nhiều điều chỉnh nhưng bị xóa trong 2.6.33 (đầu năm 2010). cfq đã trở thành mặc định một số trong khi trước đây, vì hiệu suất của nó là hợp lý và công bằng là một mục tiêu tốt cho hệ thống đa người dùng (và thậm chí cả người dùng máy tính để bàn đơn). Đối với một số trường hợp - cơ sở dữ liệu thường được sử dụng làm ví dụ, vì chúng có xu hướng có lịch biểu và mẫu truy cập riêng và thường là hầu hết các dịch vụ quan trọng (vì vậy ai quan tâm đến sự công bằng?) - anticipatory có lịch sử lâu dài có thể điều chỉnh để có hiệu suất tốt nhất trên các tải công việc này và deadline sẽ nhanh chóng chuyển tất cả các yêu cầu đến thiết bị cơ bản.

Answer 2

Mục đích của việc hỗ trợ hạt nhân là những thứ khác nhau là bạn có thể dùng thử mà không cần khởi động lại; sau đó bạn có thể chạy khối lượng công việc thử nghiệm thông qua sytsem, đo lường hiệu suất và sau đó làm cho tiêu chuẩn đó cho ứng dụng của bạn.

Trên phần cứng cấp máy chủ hiện đại, chỉ phần cứng mới có vẻ hữu ích. Những người khác dường như chậm hơn trong các bài kiểm tra của tôi.

Answer 3

Nhân Linux không tự động thay đổi Bộ lập lịch IO vào thời gian chạy. Bởi điều này tôi có nghĩa là, hạt nhân Linux, như của ngày hôm nay, không thể tự động chọn một "tối ưu" lịch trình tùy thuộc vào loại lưu trữ thứ cấp phát sinh. Trong khi khởi động, hoặc trong thời gian chạy, có thể thay đổi bộ lập lịch IO theo cách thủ công.

Trình lên lịch mặc định được chọn khi khởi động dựa trên nội dung trong tệp có tại /linux-2.6 /block/Kconfig.iosched. Tuy nhiên, có thể thay đổi bộ lập lịch IO trong thời gian chạy bằng cách echo nhập tên bộ lập lịch hợp lệ vào tệp nằm tại/sys/block/[DEV]/queue/scheduler. Ví dụ: echo deadline > /sys/block/hda/queue/scheduler

Answer 4

Có thể sử dụng quy tắc udev để cho phép hệ thống quyết định lịch trình dựa trên một số đặc điểm của hw.
Một ví dụ quy tắc udev cho SSD và ổ đĩa không quay khác có thể trông giống như

# set noop scheduler for non-rotating disks 
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop" 

bên trong một quy tắc udev mới tập tin (ví dụ, /etc/udev/rules.d/60-ssd-scheduler.rules). Câu trả lời này được dựa trên debian wiki

Để kiểm tra xem đĩa SSD sẽ sử dụng các quy tắc, nó có thể kiểm tra các thuộc tính kích hoạt trước:

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done