Messages in this thread | | | From | (Alan Cox) | Subject | Re: disk head scheduling | Date | Sun, 21 Mar 1999 17:25:18 +0000 (GMT) |
| |
> > There is indeed a global upper limit of total requests that the kernel > > will queue up, but that's a separate issue or memory management, and is > > actually just a single define.. It means that all IO requests are allocated > > It should not be a define, in my opinion, if we want the kernel IO > sub-system resources to scale the actual hardware IO system.
It is very difficult for it to not be a fixed size. If you kept queues per device you could probably allocate them when the device is loaded at best.
The reason for this is that you cannot do a memory allocation during a block I/O - since the block I/O itself may need to complete in order to free any memory. That means request queue entries cannot be dynamically allocated as they are needed.
> The main reason could be, in my opinion, that the semantic of the SCSI > layer is useless when we have to glue an abstraction of 'blocks' to > another abstraction of 'blocks'.
The SCSI layer tries to be too clever. Much too clever. It is true some of that is to get around the block layer being less than perfect for its need, but most of it is because the scsi layer is optimised for 6 year old technology, and it shows, It is a superb interface for dumb PIO scsi controllers.
Fundamentally the scsi devices should be talking directly to the block layer. That is the biggest problem with the scsi mid layer - you have to go through it, you can't just call bits of it as needed by your driver.
It really should be
block | dumbscsiadapter | scsi_queue | dumb_docmd
so that a smart controller can skip some of the scsi midlayer features that are useless to it
Alan
- 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/
| |