On Fri, Jun 21, 2002 at 05:48:27PM +0100, David Laight wrote:
> > Ah, "escalator" being "seek up, reset to beginning, seek up again"?
> 
> Yep - IIRC it has slightly better 'worse case' behavior.
> Also the 'down' path wont actually work too well - you would
> want to write sectors for a given track in increasing order.

I would expect "down" to not suffer the starvation for the profile I
posted earlier.  All the n+1 blocks would be behind the current
position.  With tagged-queuing enabled, the drive would be resorting the
requests for a given track to a more optimal pattern.

Since time(perform I/O) > time(schedule I/O), the queues would get
larger on each progressive pass.  There would still be some starvation
issues.  On the next pass, the queue may be HUGE, and take several
seconds to flush.  Each pass will only have to write out the requests
queued during the previous pass, so some there is some relief to the 
one-pass full-write worst-case.

Starvation is still there. It's muted a bit, but gets progressively
worse with each pass of a large write.

I like it because its simple and could easily be put into 1.6, if 1.6 is
still suffering this.  I don't like it because it feels like a hack to
treat a single case.

I'd be interested in seeing performance numbers with this, but I don't
see it being the answer.

On Fri, Jun 21, 2002 at 10:13:41AM -0700, Jason R Thorpe wrote:
> On Fri, Jun 21, 2002 at 05:48:27PM +0100, David Laight wrote:
> 
>  > OTOH with modern disks that have 'voice coil' head motors
>  > rather than 'stepper motors' track-track seek times are
>  > not as dependent on the number of tracks being skipped.
> 
> OTOOH, with modern disks that support tagged queuing and can
> reorder requests themselves, it's not clear we should use disksort
> at all.

I would have to disagree with that.  Our queues can grow to greatly
exceed the queue space on the disk.  Sorting the requests before handing
them off to the disk limits the range of blocks the disk is sorting,
which I would expect to improve overall performance.

Wait a sec.  What algorithm is the disk using to sort the requests?  If
we're passing them in FIFO, and it's sorting them with its version of
disksort(), could a particular request be as starved as with our
disksort(), given the same access profile?

> (Note, not all disks that support tagged queuing can reorder
> requests, and not all that can are configured to do so -- it's
> a mode page parameter, generally.)

Do the block device drivers attempt to enable it wherever possible?

jf
-- 
John Franklin
franklin@elfie.org
ICBM: 35°43'56"N 78°53'27"W