Thanks for your thoughtful responses. I initially only thought of the
elevator code in terms of affecting the order in which requests are
queued. The value of merging requests justifies the overhead even if
it is only a 16% gain over a naive implementation.
What lead me to whinge initially was that the following warning was
being
triggered when copying large files. e.g. when I do dd if=/dev/zero
of=bigfile
on my RAID array after a few hundred megabytes I get a slew of warnings.
if (nr_segments != elevator->nr_segments)
{
printk(KERN_WARNING
"%s: elevator nr_segments %d should be %d\n",
kdevname(dev), elevator->nr_segments,
nr_segments);
elevator->nr_segments = nr_segments;
}
This is in 2.3.99-pre2 kernel(XFS). Whatever is triggering it may have
since been
fixed.
-Kip
"Stephen C. Tweedie" wrote:
>
> 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/
-
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:09 EST