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:
> >
> > 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.

Indeed. However, that in turn has various other downsides (inefficient use
of resources - you'd be better off sharing at least part of the requests,
simply because one fairly common case is that one device is very active
while other devices are essentially completely inactive).

The thing that would probably be the best of both worlds is to have a
global request queue for overflow, and a per-device requests queue that is
usually fairly small. The per-device requests queue does three things:

- it guarantees that a fast device doesn't get starved by a slow one
(this is one of the most horrible things with a global allocator: slow
devices take a long time with their requests, which means that they
tend to hog them)
- have more requests for faster devices.
- avoid deadlock on things like the loopback device, where we currently
have various ugly special cases to try to make sure we don't run out of
requests.

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

That's the fundamental reason, but there's also simply the issue of just
having to say "stop" at some point. There's only so much we can reasonably
queue up: even a fast device should not need all that much more than any
other device, because if it truly _is_ fast then it should be freeing the
requests as fast as they come in. So it should never be a major issue, as
long as it has a reasonable size.

Anyway, the problem with the basic block interface is that it is currently
locked to using the major number of a device as the index into the queue.
That wasn't really how it was _meant_ to be: it was just that the early
devices had a nice "one major number for one controller" setup, so the 1:1
mapping was the simplest one.

These days people are so used to "major number indexes the request queue",
that people don't even realize that it wasn't meant to be taken that way.
For devices with multiple request queues for the same major number there
should simply be a mapping function or something simple like that. But
nobody has ever gotten quite interested enough to clean this up, and
instead we've just added more and more special cases to ll_rw_block.c.

Oh, well..

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.565 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site