Re: RFC on io-stalls patch

[Jens Axboe <axboe@suse.de>]

On Mon, Jul 14 2003, Chris Mason wrote:
> On Mon, 2003-07-14 at 18:45, Andrea Arcangeli wrote:
> > On Mon, Jul 14, 2003 at 04:34:41PM -0400, Chris Mason wrote:
> > > patch.  It's a good starting point for the question "can we do better
> > > for reads?" (clearly the answer is yes).
> > 
> > Jens's patch will block every writers until the parallel sync readers go
> > away.  if we add a 5 seconds delay for every write, sure readers will
> > run faster too in contest, and in turn it's not obvious to me it's
> > necessairly a good starting point.  
> 
> For real server workloads I agree the patch isn't a good idea.  But
> Jens' workload had a small number of kernel compilers (was it one proc
> or make -j4 or so?), so clearly the writers could still make progress. 
> This doesn't mean I want the patch but it does mean the numbers are
> worth thinking about ;-)
> 
> If we go back to Jens' numbers:
> 
> ctar_load:
> Kernel            [runs]        Time    CPU%    Loads   LCPU%   Ratio
> 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
>                                                ^^^^^^
> The loads column is the number of times ctar_load managed to run during
> the kernel compile, and the patched kernel loses each time.  This must
> partially be caused by the lower run time overall, but it is still
> important data.  It would be better if contest gave us some kind of
> throughput numbers (avg load time or something).

Well, look at the ratio given the run times listed. You'll see that they
are extremely close (0.1064 for 2.4.22-pre5 vs 0.1015 for
2.4.22-pre5-axboe).

It just shows that we are not hitting the possible bad problems in these
work loads.

-- 
Jens Axboe