lkml.org 
[lkml]   [1999]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.097 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site