The parameters are set in files located at:
For example, the parameter read_expire on a device hda is stored in:
The parameter can be set to 80 (milliseconds) using the command:
echo 80 > /sys/block/hda/queue/iosched/read_expire
This has five tunable parameters:
- read_expire - the most important parameter for the deadline scheduler, it dictates
the maximum time a read request must wait before being serviced.
- write_expire - the maximum time before a write request must be serviced.
- fifo_batch - the number of requests in each batch sent for immediate servicing once
they have expired.
- writes_starved - this alters the amount of priority that read requests get over
write requests. Since unserviced reads affect performance more than unserviced writes,
it's usual that reads get some measure of priority.
- front_merges - this is disabled by default. Setting its value to 1 results in
requests contiguous to existing requests in the scheduler being merged to the front of
the queue instead of the back.
In addition to read_expire and write_expire, the anticipatory scheduler also
- read_batch_expire - the time spent servicing read requests before servicing pending
- write_batch_expire - the reverse of the above
- antic_expire - the time in milliseconds that the scheduler pauses while waiting for
a follow-on request from an application before servicing the next request in the
- quantum - the number of internal queues that the requests are taken from in one
cycle and moved to the dispatch queue for processing. The cfq scheduler may have 64
internal queues, but only move requests to the dispatch queue by visiting the first
eight internal queues, followed by the second eight in the next cycle, and so on.
- queued - the maximum number of requests allowed in a given internal queue.
Although there are no hard and fast rules, a sensible strategy is probably to
benchmark I/O using different schedulers with their default parameter settings, and then
to choose the most appropriate scheduler and attempt to fine-tune the parameter settings
by referring to application-specific recommendations.
Don't forget that scheduling isn't the be all and end all of I/O optimization. Other
factors that can affect performance include prefetching, disk capacity and spin rate
(because these can affect seek time) and even the file system you choose for a given
disk. One thing is certain: Whatever performance you are getting now, you can almost
certainly improve it if you have the time, the will and the knowledge.
Paul Rubens is an IT consultant and journalist based in Marlow on Thames, England.
He has been programming, tinkering and generally sitting in front of computer screens
since his first encounter with a DEC PDP-11 in 1979.
Article courtesy of ServerWatch