Re: RFC on io-stalls patch

Jens Axboe (axboe@suse.de)
Tue, 15 Jul 2003 07:43:04 +0200


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

- 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/