Re: iozone write 50% regression in kernel 2.6.24-rc1

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Tue, 2007-11-13 at 10:19 +0800, Zhang, Yanmin wrote:
> On Mon, 2007-11-12 at 17:48 +0100, Peter Zijlstra wrote:
> > On Mon, 2007-11-12 at 17:05 +0200, Benny Halevy wrote:
> > > On Nov. 12, 2007, 15:26 +0200, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > > > Single socket, dual core opteron, 2GB memory
> > > > Single SATA disk, ext3
> > > > 
> > > > 2.6.23.1-42.fc8 #1 SMP
> > > > 
> > > >           524288       4  225977  447461
> > > >           524288       4  232595  496848
> > > >           524288       4  220608  478076
> > > >           524288       4  203080  445230
> > > > 
> > > > 2.6.24-rc2 #28 SMP PREEMPT
> > > > 
> > > >           524288       4   54043   83585
> > > >           524288       4   69949  516253
> > > >           524288       4   72343  491416
> > > >           524288       4   71775  492653
> > 
> > 2.6.24-rc2 +
> >         patches/wu-reiser.patch
> >         patches/writeback-early.patch
> >         patches/bdi-task-dirty.patch
> >         patches/bdi-sysfs.patch
> >         patches/sched-hrtick.patch
> >         patches/sched-rt-entity.patch
> >         patches/sched-watchdog.patch
> >         patches/linus-ext3-blockalloc.patch
> > 
> >           524288       4  179657  487676
> >           524288       4  173989  465682
> >           524288       4  175842  489800
> > 
> > 
> > Linus' patch is the one that makes the difference here. So I'm unsure
> > how you bisected it down to:
> > 
> >   04fbfdc14e5f48463820d6b9807daa5e9c92c51f
> Originally, my test suite is just to pick up the result of first run. Your prior
> patch(speed up writeback ramp-up on clean systems) fixed an issue about first
> run result regression. So my bisect captured it.
> 
> However, late on, I found following run have different results. A moment ago,
> I retested 04fbfdc14e5f48463820d6b9807daa5e9c92c51f by:
> #git checkout 04fbfdc14e5f48463820d6b9807daa5e9c92c51f
> #make
> 
> Then, reverse your patch. It looks like 04fbfdc14e5f48463820d6b9807daa5e9c92c51f
> is not the root cause of following run regression. I will change my test suite to
> make it run for many times and do a new bisect.
> 
> > These results seem to point to
> > 
> >   7c9e69faa28027913ee059c285a5ea8382e24b5d
My new bisect captured 7c9e69faa28027913ee059c285a5ea8382e24b5d
which caused the regression of iozone following run (3rd/4th... run after mounting
the ext3 partition).

Peter,

Where could I download Linus new patches, especially patches/linus-ext3-blockalloc.patch?
I couldn't find it in my archives of LKML mails.

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