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

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