On Tue, Jul 15, 2003 at 05:12:28AM -0400, Chris Mason wrote:
> On Tue, 2003-07-15 at 04:28, Jens Axboe wrote:
>
> > Definitely, because prepare to be a bit disappointed. Here are scores
> > that include 2.4.21 as well:
>
> > 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
>
> Huh, this is completely different than io_load on my box (2P scsi, ext3,
> data=writeback)
>
> io_load:
> Kernel [runs] Time CPU% Loads LCPU% Ratio
> 2.4.21 3 520 52.5 27.8 15.2 3.80
> 2.4.22-pre5 3 394 69.0 21.5 15.4 2.90
> 2.4.22-sync 3 321 84.7 16.2 15.8 2.36
this is what I remeber from Con's results too when he benchmarked my
first trees where I introduced the lowlatency elevator. I thought it was
the 4M queue that screwed stuff but clearly 4M is still way better than
2.4.21 stock. it's an exponential thing, I remeber very well, the huge
degradation from 2M to 4M, or at 1M for example the responsiveness is
istant an order of magnitude better than 2M. It's not a linear response.
So I thought the 4M thing hidden the benefits after reading Jens's
number, but it was quite surprising anyways since in 2.4.21 the queue is
way bigger than 4M anyways that puts all reads at the end with an huge
delay compared to pre5.
> Where 2.4.22-sync was the variant I posted yesterday. I don't really
> see how 2.4.21 can get numbers as good as 2.4.22-pre5 on the io_load
> test, the read starvation with a big streaming io is horrible.
Agreed, something looked strange. Maybe it's some scsi/ide variable that
makes the difference, dunno. I tested this stuff on scsi IIRC though
(not that it should make any huge difference either ways though).
> BTW, the contest run times vary pretty wildy. My 3 compiles with
> io_load running on 2.4.21 were 603s, 443s and 515s. This doesn't make
> the average of the 3 numbers invalid, but we need a more stable metric.
we definitely need many many more runs if the variance is so huge. And
it's not surprising it's so huge, the variable block allocation as well
plays a significant role.
Andrea
-
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:56 EST