Messages in this thread | | | Date | Wed, 5 Apr 2006 13:48:55 +0200 | From | "Antonio Vargas" <> | Subject | Re: CSCAN I/O scheduler for 2.6.10 kernel |
| |
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/
| |