Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 16 Apr 2003 09:28:43 -0400 | From | Chuck Ebbert <> | Subject | Re: Benefits from computing physical IDE disk geometry? |
| |
> The way you would do a good "goodness" function, I guess, > would be to search through all requests on the device, and return > the minimum distance from the request you are running the query > on. Do this for both queues, and insert the request into the > queue with the smallest delta. I don't see much else doing any > good.
That would be perfect. And like you say in a later message, they're in a tree so it might actually work. Then the read balance code wouldn't need to do that calculation at all.
How hard would this be to add?
> On the other hand, if you simply have a fifo after the RAID > scheduler, the RAID scheduler itself knows where each disk's > head will end up simply by tracking the value of the last > sector it has submitted to the device. It also has the advantage > that it doesn't have "high level" scheduling stuff below it > ie. request deadline handling, elevator scheme, etc. > > This gives the RAID scheduler more information, without > taking any away from the high level scheduler AFAIKS.
But then wouldn't you have to put all that into the RAID scheduler?
-- Chuck - 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/
| ![\](/images/icornerr.gif) |