Messages in this thread | | | Date | Sun, 21 Mar 1999 09:41:21 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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/
| |