Messages in this thread | | | Date | Sun, 21 Mar 1999 19:52:15 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: disk head scheduling |
| |
On Sun, 21 Mar 1999, Alan Cox wrote:
> > > 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.
A imaginary perfectly designed system should be able to run with only one buffer of each kind, but just would perform poorly. On the other hand, without a minimal reserve of memory ensured by a not too stupid VM policy, you can deadlock at any time on real systems, since they donnot guarantee that no allocation will occur when having to swap out things.
> > 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
It is a try that seems to never have succeeded. ;-)
> 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.
The SCSI layer was broken design in the first place, in my opinion. Just reading some old comments prooves my statement. And the 'one queue problem' I missed since I could'nt imagine a nano-second such thing may exist is the same story. I have had a look into the sd code of 2.2.3 and I didn't see for the moment any severe design problem that keeps from getting rid of the 'one queue problem'.
> 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
The work of the mid-layer should normally be minimal for actual block IOs and rather smart than clever, in my opinion.
> Alan
Regards, 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/
| |