Re: CSCAN I/O scheduler for 2.6.10 kernel

["Antonio Vargas" <windenntw@gmail.com>]

On 4/4/06, Vishal Patil <vishpat@gmail.com> wrote:
> In that case it would be a normal elevator algorithm and that has a
> possiblity of starving the requests at one end of the disk.
>
> - Vishal
>
> On 4/4/06, Bill Davidsen <davidsen@tmr.com> wrote:
> > Vishal Patil wrote:
> > > Maintain two queues which will be sorted in ascending order using Red
> > > Black Trees. When a disk request arrives and if the block number it
> > > refers to is greater than the block number of the current request
> > > being served add (merge) it to the first sorted queue or else add
> > > (merge) it to the second sorted queue. Keep on servicing the requests
> > > from the first request queue until it is empty after which switch over
> > > to the second queue and now reverse the roles of the two queues.
> > > Simple and Sweet. Many thanks for the awesome block I/O layer in the
> > > 2.6 kernel.
> > >
> > Why both queues sorting in ascending order? I would think that one
> > should be in descending order, which would reduce the seek distance
> > between the last i/o on one queue and the first on the next.
> >

But, if there are two queues, one which is being processed and other
which gets the new requests (and the corresponding queue switch when
the current is empty), then there is no way to get starved when they
are sorted in opposite order.


--
Greetz, Antonio Vargas aka winden of network

http://wind.codepixel.com/
windNOenSPAMntw@gmail.com
thesameasabove@amigascne.org

Every day, every year
you have to work
you have to study
you have to scene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/