Hi,
On Mon, May 01, 2000 at 04:37:11PM +0200, Arjan van de Ven wrote:
>
> > True, but only if the memory survives a reboot. However, even in
> > these situations, the elevator serves a useful purpose --- it allows
> > us to merge adjacent IO requests together in the queue, letting us
> > reduce the number of hardware IOs we generate.
>
> My experiments have shown that a typical (ie the current) elevator merges
> about 70% of the requests, while a "simple" elevator that only tries to
> merge the previous request (without the sorting) merges about 60%. So the
> gain of sorting for merging is just 10%points.
So for every 30 requests we are left with with the elevator, we have
40 request without it. That's an increase of 33% in the number of
requests we have to deal with. That sounds like a worthwhile
optimisation to me.
> Another issue with RAID: If two adjacent requests (that could be merged)
> fall in different 64Kb blocks, a RAID array might be able to processes the
> second request because the relevant disk for that request is idle, while
> after the merge the request wouldn't be processed "out of order". It would
> even have to be split again.
It doesn't make any difference.
For direct mappings such as raid0 or LVM, we process the remappings
before doing the merge code, so these requests will still be processed
in parallel whenever possible. For raid1/5, the raid code takes the
requests immediately and queues independent sub-requests to the
component devices. In either case, we don't let busy devices hold
up idle ones, even with the elevator algorithm in place.
--Stephen
-
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/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:08 EST