Re: RFC on io-stalls patch

[Andrea Arcangeli <andrea@suse.de>]

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