Re: linux-kernel-digest V1 #2824 (was: elevator)

Nathan Hand (nathanh@wookie.chirp.com.au)
Mon, 16 Nov 1998 14:30:36 +1100 (EST)


On Sun, 15 Nov 1998, Jeffrey B. Siegal wrote:

> >On Fri, 13 Nov 1998, Jeffrey B. Siegal wrote:
> >
> >> I vaguely recall reading in some operating system book that
> >> this is modified version of the elevator algorithm
> >> meant increase fairness. Otherwise, the access to block 5
> >> might be delayed a *long* time if lots of high-value
> >> blocks are requested.
> >
> >But it will never be starved. I do not have hard figures, but I'd
> >make an educated guess that the modification Philip proposed will
> >be beneficial more often than not.
>
> That depends on how you define benefit. It will decreae the mean
> service time, but increase the service time variance. Is that
> beneficial? It depends.

I saw it as increasing the worst case time, but decreasing the time
required to service all requests. My guess was that this works well
for single user systems, where you would prefer to reduce the start
time for applications by favouring contiguous reads.

> Also, adding accesses to the current pass will bias accesses such those
> at the end of the disk will be serviced faster than those at the
> beginning. This is similar to the one-way vs. two-way elevator issue
> discussed by others.

No, it biasses equally for both start and end sectors. You can view
the one-way elevator algorithm like a circle. There's no concept of
start or end sector if you consider it this way. The return seek is
not important: end sectors are affected by that time delay also.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/