> My argument is that a sufficiently smart kernel scheduler *should*
> yield performance results that are reasonably close to what you can
> get with that feature. Perhaps not quite as good, but reasonably
> close. It shouldn't be an orders-of-magnitude type difference.
And a controller card (or drive) has a lot less RAM to use as a cache /
queue for reordering stuff than the OS has, potentially the OS can us most
of the available RAM, which can be gigabytes on a big server, whereas in
the drive there are at most a few tens of megabytes...
However all this is a bit looking at the problem through the wrong end.
The OS should provide a multi-read call for the applications to pass a
list of blocks they'll need, then reorder them and read them the fastest
possible way, clustering them with similar requests from other threads.
Right now when a thread/process issues a read() it will block until the
block is delivered to this thread. The OS does not know if this thread
will then need the next block (which can be had very cheaply if you know
ahead of time you'll need it) or not. Thus it must make guesses, read
ahead (sometimes), etc...
