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 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/

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