Re: 2.4.20: Proccess stuck in __lock_page ...

[Andrea Arcangeli <andrea@suse.de>]

On Tue, May 27, 2003 at 03:40:49PM -0700, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > On Tue, May 27, 2003 at 03:18:30PM -0700, Andrew Morton wrote:
> > > Andrea Arcangeli <andrea@suse.de> wrote:
> > > >
> > > > However the last numbers from Randy showed my tree going faster than 2.5
> > > > with bonnie and tiotest so I think we don't need to worry and I would
> > > > probably not fix it in a different way in 2.4 even if it would mean a 1%
> > > > degradation.
> > > 
> > > That could be because -aa quadruples the size of the VM readahead window.
> > > 
> > > Changes such as that should be removed when assessing the performance
> > > impact of this particular patch.
> > 
> > I understand that was a generic benchmark against 2.5, not meant to
> > evaluate the effect of the fixed readahead (see the name of the patch
> > "readahead-got-broken-somehwere"). I don't see any good reason why
> > should Randy cripple down my tree before benchmarking against 2.5? if
> > something it's ok to apply some of my patches to 2.5, that's great, the
> > other way around not IMHO.
> > 
> 
> No.
> 
> What I am saying is that evaluation of the effect of an IO scheduler change
> cannot be performed when there is a 4:1 change in the readhead window present
> in the same tree.
> 
> ie: we cannot conclude anything about the effect of the IO scheduler change
> from Randy's numbers.  Too many variables.

an accurate evaluation can't be made from such comparison, but I never
claimed that to be an accurate evaluation, I just said we don't need to
worry, == "can't be too bad".

I just said it can't be too bad. and this is true, you even admit that a
readahead change for sure has more impact than whatever change the
fix-pausing generated. That's all I meant. Can't be too bad. the fact
mainline doesn't do readahead properly is much worse thing than whatever
slowdown can be generated by the fix pausing.

Furthmore I said we can deduce the accurate numbers from bigbox.html,
with very minor changes (not 2.4 vs 2.5) that as well shows the fix for
the deadlock not measurable as far as I can tell.

Andrea