On Tue, Jul 15 2003, Andrea Arcangeli wrote:
> On Tue, Jul 15, 2003 at 08:08:57AM +0200, Jens Axboe wrote:
> > I don't see the 31% slowdown. We complete less tar loads, but only
> > because there's less time to complete them in. Well almost, as you list
>
> I see, so I agree the writer wrote at almost the same speed.
Good
> > I see tar making progress, how could it be stopped?
>
> I didn't know the load was stopped after 249 seconds, I could imagine it,
> sorry. I was probably obfuscated by the two severe problems the code had
> that could lead to what I was expecting with more readers running
> simultanously.
>
> So those numbers sounds perfectly reproducible with a fixed patch too.
Yes
> At the light of this latest info you convinced me you were right, I
> probably understimated the value of the separated queues when I dropped
> it to simplify the code.
Ok, so we are on the same wave length know :)
> I guess waiting the batch_sectors before getting a request for a read
> was allowing another writer to get it first because the other writer was
> already queued in the FIFO waitqueue when the writer got in. that might
> explain the difference, the reserved requests avoid the reader to wait
> for batch_sectors twice (that translates in 1/4 of the queue less to
> wait at every I/O plus the obvious minor saving in less schedules and
> waitqueue registration).
That is one out come, yes.
> It'll be great to give another boost to the elevator-lowlatency thanks
> to this feature.
Definitely, because prepare to be a bit disappointed. Here are scores
that include 2.4.21 as well:
no_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.21 3 133 197.0 0.0 0.0 1.00
2.4.22-pre5 2 134 196.3 0.0 0.0 1.00
2.4.22-pre5-axboe 3 133 196.2 0.0 0.0 1.00
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.21 3 190 140.5 15.0 15.8 1.43
2.4.22-pre5 3 235 114.0 25.0 22.1 1.75
2.4.22-pre5-axboe 3 194 138.1 19.7 20.6 1.46
2.4.22-pre5-axboe is way better than 2.4.21, look at the loads
completed.
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.21 3 287 93.0 14.0 15.3 2.16
2.4.22-pre5 3 309 86.4 15.0 14.9 2.31
2.4.22-pre5-axboe 3 249 107.2 11.3 14.1 1.87
2.4.21 beats 2.4.22-pre5, not too surprising and expected, and not
terribly interesting either.
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.21 3 543 49.7 100.4 19.0 4.08
2.4.22-pre5 3 637 42.5 120.2 18.5 4.75
2.4.22-pre5-axboe 3 540 50.0 103.0 18.1 4.06
2.4.22-pre5-axboe completes the most loads here per time unit.
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.21 3 581 46.5 111.3 19.1 4.37
2.4.22-pre5 3 576 47.2 107.7 19.8 4.30
2.4.22-pre5-axboe 3 452 59.7 85.3 19.5 3.40
2.4.22-pre5 is again the slowest of the lot when it comes to
workloads/time, 2.4.22-pre5 is again the fastest and completes the work
load in the shortest time.
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.4.21 3 151 180.1 8.3 9.3 1.14
2.4.22-pre5 3 150 181.3 8.1 9.3 1.12
2.4.22-pre5-axboe 3 152 178.9 8.2 9.9 1.14
Pretty equal.
I'm running a fixed variant 2.4.22-pre5 now, will post results when they
are done (in a few hours).
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:55 EST