Hardware Reference
In-Depth Information
Understanding the CFQ Scheduler
Let's take a look at how the CFQ works. In Figure
2-18
you can see two processes called “Process 1” and “Process 2.”
Each process has a block of pending I/O. For Process 1 this is “I/O 1 and I/O 2” and for Process 2 this is “I/O 3.” In the
CFQ the blocks of I/O get grouped together so that the underlying hard disk won't need to seek on disk as much. The
syslog, for example, may have two blocks of I/O: they are each appended to the same log file on disk. In the case of a
traditional hard disk, this makes sense.
Process 2
Process 1
I/O
1
I/O
2
I/O
3
S
S
1
2
HDD
Figure 2-18.
The CFQ scheduler
This sounds good. So how can you tell what your I/O scheduler is?
Quite simple. You can make use of the
sys
filesystem to see what the current I/O scheduler is. Just find the
/sys/block/mmcblk0/queue/scheduler
file and look at its output. Do note that
mmcblk0
is what the Linux kernel
sees our block device (SD card) as. If you look at Figure
2-19
you can see that the CFQ has brackets around it; that's
the current scheduler in use.
Figure 2-19.
The current I/O scheduler in use
You can see by default that Fedora uses the CFQ. So what's bad about the CFQ? The CFQ makes two main
assumptions that are not the best for Raspberry Pi users; after all, we don't have standard hardware or a traditional
block device. The two assumptions of the CFQ are as follows:
•
Your hard drive needs to move a physical read/write head around the disk platter.
•
On a modern system, CPU cycles are plentiful.
It also assumes that CPU cycles are plentiful and that the underlying block device has some form of access
latency. Now the Raspberry Pi needs all the CPU cycles it can get. If you can make the I/O scheduler put less load on
the CPU and still get performance for the workload in question, it would seem like a good idea. Second, an SD card
has very little access latency. A block request on the SD card could have less than one millisecond of access time,
