Re: elevator algorithm bug in ll_rw_blk.c

Riley Williams (rhw@bigfoot.com)
Sun, 15 Nov 1998 19:16:48 +0000 (GMT)


Hi Alan.

>>> that single IO request is complete, the driver then moves on to
>>> the *next* request in the queue. It doesn't start again at the
>>> beginning. So, we do correctly service the higher numbered
>>> requests before going back to the low ones.

>> But that's a *one-way* elevator. Ideal elevators are two-way,
>> aren't they?

> If you go for the shortest movement alone you starve the edges of
> the disks. If you watch a real elevator you'll see they too use the
> elevator algorithm...

I think you two are talking at cross-purposes here, so can I state my
understanding of what's being said?

If I'm following the discussion correctly, Alan, you've described the
current method as being that the kernel starts the head at track 0,
working its way across the disk surface to track 999,999 (or whatever
the highest track number is), then zooms back to track 0 for another
scan from track 0 to track 999,999.

Your correspondant appears to be claiming that what should be
happenning is that the head starts from track 0 and works its way
across the disk to track 999,999 on one pass, and on the next pass, it
works its way from track 999,999 back to track 0 reading sectors as it
goes in BOTH directions.

I haven't analysed the code on this point, the above are entirely from
the discussion that's been going on, so no flames please...

However, I can see obvious advantages of the latter method over the
former...

Also, one other question: If, whilst the head's working its way across
the disk from track 0 to track 999,999 reading sectors, a request
arrives for a sector on a track that the head has not yet reached, do
we queue that request for the current pass or the next one?

Best wishes from Riley.

-
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/