On 8/4/06, Al Boldi <[email protected]> wrote:
Nate Diller wrote:
> This is the Elevator I/O scheduler. It is a simple one-way elevator,
Thanks for yet another attempt to achieve an efficient 2.6 elevator.
hopefully it's useful for you, I'd love to see performance results one
way or the other.
> +static inline char contig_char(struct el_request *e)
You probably meant el_req. Check the rest.
> +static void print_queue(struct request_queue *q, struct el_data *el)
> +{
> + struct el_req *e;
> +
> + printel(el);
Should be print_el_data.
Applied against 2.6.17, it boots with this:
io scheduler elevator registered (default)
elevator: forced dispatching is broken (nr_sorted=13), please report this
damn, i thought i fixed that.
> +In pure form its largest weakness is starvation of other processes due to
> +one process writing a very large number of contiguous requests (e.g.
> +tarring a very large tar file while other processes are trying to run).
cat /dev/hda > /dev/null starves the rest of the system.
yeah, that can be worse on some systems than others, it seems to vary
a bit with file system and device driver. some setups cause more
"breaks" in the stream of requests.
> +The max_contig and max_write tunables are two (imperfect) solutions. They
> +
> +These two tunables are still under construction, but they have proven
> +somewhat useful in practice. Usually, max_contig should be the same size
> +(in bytes) as ra_pages.
It's 0 by default. Setting it to ra_pages prints this:
nate 1977: max_contig went backwards
hmmm, haven't tested this recently. dunno why that would have broken...
> +
> + SSTF
> +
> +The SSTF feature was added on a whim. It ignores the tunables, and
> probably +breaks tracing. I didn't ever see it perform better than SCAN,
> but who +knows?
Starves too.
oh, yeah, definitely, this algorithm is only suitable for a workload
where you want latency over fairness. suppose i should mention that.
Thanks for your comments and testing
NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
