Messages in this thread | | | Date | Mon, 22 Mar 1999 00:17:05 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: disk head scheduling |
| |
On Sun, 21 Mar 1999, Linus Torvalds wrote:
> Anyway, the problem with the basic block interface is that it is currently > locked to using the major number of a device as the index into the queue. > That wasn't really how it was _meant_ to be: it was just that the early > devices had a nice "one major number for one controller" setup, so the 1:1 > mapping was the simplest one.
But the code seems to plug the major, thus the controller, but says that it plugs the device. This perhaps didn't affected performances with early controllers. Now, it is allowed to have queues based on kdev_t value, but the code still seems to plug the major. This looks too me like some incomplete enhancement, btw.
> These days people are so used to "major number indexes the request queue", > that people don't even realize that it wasn't meant to be taken that way. > For devices with multiple request queues for the same major number there > should simply be a mapping function or something simple like that. But
Hmmm ... Not that simple. The queuing model that must be used depends on the low-level sub-system being involved. You may have some hierarchy with limits for queuing and you donnot want to hang-up or to do bad things. Too much links or mappings in the blkdevs will make things way complex, in my opinion. The only thing we should want to do from ll_rw_blk.c is to plug the right things we want to sort requests and coalesce IOs for, in my opinion.
> nobody has ever gotten quite interested enough to clean this up, and > instead we've just added more and more special cases to ll_rw_block.c.
It is how the code seems to have evolved.
> Oh, well..
May-be not so well, but nothing is perfect. :)
> Linus
Gérard.
- 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/
| |