Quote:
|
When elevator=noop is passed as boot command line parameter and not passed as a boot parameter, there is a difference in I/O performance. In the former case it is 20 MBPS and in the latter case it is 56 MBPS
|
I don't understand the distinction here. Can you give a
specific example?
Anyhow... the various I/O-scheduling algorithms can indeed make a difference and they are a "hidden treasure" in the current crop of 2.6 kernels.
see (in
/usr/src/linux/Documentation/) ...
- block/as-iosched.txt
- block/biodoc.txt
- kernel-parameters.txt
- block/switching-sched.txt
(If you do not have these files, you may have to install some kind of "kernel source" or "kernel documentation" package on your system.)
Remember, however, that these so-called "anticipatory I/O schedulers" are not a silver bullet. Everything in the computer world is a system of intelligent tradeoffs. Each one makes certain
assumptions about the pattern of I/O requests that you will be issuing and what is more important to your workload: "what you are willing to trade (and assuming that you have it to trade), to get what benefit."
First of all, these schedulers all assume that your system does a lot of I/O, and that you possess the hardware-configuration needed to handle a large number of I/O transactions ... to move the data quickly, from disks that spin quickly, and so-much-the-better if many such transfers can be going on simultaneously in the hardware.
What a scheduler then tries to do is to sort-out the requests so that the hardware is utilized more efficiently,
and/or so that the I/O requests are completed quickly; the two objectives not always being equivalent. "Elevator" scheduling thinks about
seek time, which is the time spent moving the read/write head from track to track. "Deadline" scheduling thinks more about
latency, which is the length of time any process might spend waiting for
its requests to complete.
Many consumer-oriented computers just use the I/O controllers which are built-in to the motherboard. These are characteristically no more than "adequate," as are the devices they are connected to. Higher performance is available, through the use of external controllers and generally more expensive devices. If you're running a "server" or "gaming" system,
this in my opinion is a much more-important consideration than, say, the speed of the CPU. On the other hand, in a consumer machine servicing a single piece of wetware (that would be "you" ...) fiddling with the scheduler parameters might make little difference.
If you
do want to "fiddle," observe that per the
block/switching-sched.txt document, you can experiment with multiple schedulers without rebooting or reconfiguring your machine.
