From: Mary Edie Meredith
Date: Tue Mar 30 2004 - 16:37:49 EST
The 2.6.5-rc2-mm5 kernel has vastly improved the
performance issue with dbt3-pgsql throughput numbers
(bigger is better):
290357 141.84 2788 2.6.5-rc2..... base
290576 91.18 2814 2.6.5-rc2-mm2 -35.72
290856 60.02 2842 2.6.5-rc2-mm4 -57.68
290953 134.10 2849 2.6.5-rc2-mm5 -5.46 <-------
Thanks to Nick and Ingo.
On Tue, 2004-03-23 at 16:07, Mary Edie Meredith wrote:
> On Tue, 2004-03-23 at 11:32, Andrew Morton wrote:
> > Mary Edie Meredith <maryedie@xxxxxxxx> wrote:
> > >
> > > > 36% regression due to the CPU scheduler changes? ow.
> > > >
> > > > And that machine is a PIII, so presumably the setting of CONFIG_SCHED_SMT
> > > > makes no difference.
> > > >
> > > > >From a quick look at the material you have there it appears that this
> > > > workload also is very I/O bound. It's a little surprising that the CPU
> > > > scheduler could make so much difference.
> > > I'm not sure why you think this is IO bound. For
> > > the throughput phase of the test (from which the
> > > metric above is taken) there is very little physical
> > > IO except at the start when the updates occur. They
> > > finish in a few minutes, after which there is very
> > > little.
> > >
> > > http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat_io.png
> > > http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat.txt
> > There seems to be a large amount of idle time in the profiles and in the
> > vmstat trace.
> Yes. There is considerably more idle time in the bad run:
> Good one:
> Bad one:
> I am concerned with the drop in CPU utilization relative to
> the other run.
Mary Edie Meredith
Open Source Development Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/