Re: disk speed regression kernel 2.6.29 and after

Re: disk speed regression kernel 2.6.29 and after

[Frans Pop]

Bartlomiej Zolnierkiewicz wrote:
> Regarding additional pursue of the root cause, I think that it is not
> worth the effort currently since there were no other reports about
> similar problems and libata is a better solution on most modern systems
> anyway. 

I'm surprised at this, especially if the commit Will bisected it to [1] is 
the culprit. That is a change in generic ide code and could thus very well 
affect other users too.

This is a clear regression and IMHO, if it is confirmed that that commit is 
the cause of the regression, it should be fixed. And if not, it could 
still be worthwhile to track down which commit is the cause.

As for the lack of other reports, that could very well simply be because:
1) there are not that many users of IDE drivers anymore
2) most users don't really consciously watch their disk speed

As long as the IDE code is in mainline, I don't see why regressions should 
be ignored. Adding the ide list and David to CC for other opinions.

Cheers,
FJP

[1] http://lkml.org/lkml/2009/9/23/550

Re: disk speed regression kernel 2.6.29 and after

[Bartlomiej Zolnierkiewicz]

On Thursday 24 September 2009 20:11:18 Frans Pop wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Regarding additional pursue of the root cause, I think that it is not
> > worth the effort currently since there were no other reports about
> > similar problems and libata is a better solution on most modern systems
> > anyway. 
> 
> I'm surprised at this, especially if the commit Will bisected it to [1] is 
> the culprit. That is a change in generic ide code and could thus very well 
> affect other users too.
> 
> This is a clear regression and IMHO, if it is confirmed that that commit is 
> the cause of the regression, it should be fixed. And if not, it could 
> still be worthwhile to track down which commit is the cause.

If somebody would like to do it please go ahead.

Unfortunately I have absolutely no time to work on IDE anymore as I have
moved on other projects so unless the issue have no known solution/workaround
(this one has such) I'm rather reluctant to pick it up as there is a plenty
of more higher-prio kernel wide issues (including things like mm regressions)
to fix.

> As for the lack of other reports, that could very well simply be because:
> 1) there are not that many users of IDE drivers anymore
> 2) most users don't really consciously watch their disk speed

or more likely:

3) the issue is highly configuration dependent and not worth the hassle
   given the known solution/workaround

> As long as the IDE code is in mainline, I don't see why regressions should 
> be ignored. Adding the ide list and David to CC for other opinions.

BTW Please always Cc: David first on all IDE issues as he is the main IDE
slave now and the transition period is long over.

Re: disk speed regression kernel 2.6.29 and after

[David Miller]

I'll look closely at this at the next opportunity.

Thanks for bringing it to my direct attention.
:-)