Messages in this thread | | | Date | Sun, 21 Mar 1999 18:27:56 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: disk head scheduling |
| |
On Mon, 22 Mar 1999, Gerard Roudier wrote: > > 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.
Think of it as not "device" nor "controller" and certainly not as "major" (even though the latter is the thing that is actually closest to the actual implementation).
This of it as "scheduling entity". It then depends a lot on the actual hardware what such a scheduling entity is.
For example, for floppy drives and IDE disks, you really cannot schedule across the controller, because while there are multiple devices per controller, they are not independent of each other.
For SCSI, in contrast, the correct scheduling to use is probably device-based rather than anything else.
This is an example of something where the code really shouldn't make any policy decisions: there should be a mapping from device number to "request queue", and that mapping depends on the device. The obvious way to do this is to just have a per-major-number mapping function or similar.
Note that it really shouldn't be all that much work to change the actual ll_rw_block.c layer - all the work is really in the devices themselves (adding the mapping function, and making sure the SCSI layer in particular can live with multiple queues).
Linus
- 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/
| |