2.6.32-rc1-git2: Reported regressions 2.6.30 -> 2.6.31

On Monday 26 October 2009, Frans Pop wrote:
> On Tuesday 20 October 2009, Mel Gorman wrote:
> > I've attached a patch below that should allow us to cheat. When it's
> > applied, it outputs who called congestion_wait(), how long the timeout
> > was and how long it waited for. By comparing before and after sleep
> > times, we should be able to see which of the callers has significantly
> > changed and if it's something easily addressable.
>
> The results from this look fairly interesting (although I may be a bad
> judge as I don't really know what I'm looking at .
>
> I've tested with two kernels:
> 1) 2.6.31.1: 1 test run
> 2) 2.6.31.1 + congestion_wait() reverts: 2 test runs

I've taken another look at the data from this debug patch, resulting in
these graphs: http://people.debian.org/~fjp/tmp/kernel/congestion.pdf

I think the graph may show the reason for the congestion_wait() regression.
Horizontal axis shows time, vertical axis shows number of logged
congestion_wait calls per type.

The top chart is without the revert, the bottom one after the revert.

Note how before the revert the graph shows distinct steps: first you get
almost exclusively kwapd, followed by almost exclusively alloc_pages and
try_to_free. I suspect the periods where kswapd is almost horizontal
correspond to the freezes.

With the revert the lines for the different functions are almost straight
and everything happens much better interspersed.

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thursday 05 November 2009, Frans Pop wrote:
> On Monday 26 October 2009, Frans Pop wrote:
> > On Tuesday 20 October 2009, Mel Gorman wrote:
> > > I've attached a patch below that should allow us to cheat. When it's
> > > applied, it outputs who called congestion_wait(), how long the
> > > timeout was and how long it waited for. By comparing before and
> > > after sleep times, we should be able to see which of the callers has
> > > significantly changed and if it's something easily addressable.
> >
> > The results from this look fairly interesting (although I may be a bad
> > judge as I don't really know what I'm looking at .
> >
> > I've tested with two kernels:
> > 1) 2.6.31.1: 1 test run
> > 2) 2.6.31.1 + congestion_wait() reverts: 2 test runs
>
> I've taken another look at the data from this debug patch, resulting in
> these graphs: http://people.debian.org/~fjp/tmp/kernel/congestion.pdf
>
> I think the graph may show the reason for the congestion_wait()
> regression. Horizontal axis shows time, vertical axis shows number of
> logged congestion_wait calls per type.

I'm sorry. My initial version had a skewed time axis (showed occurrences
instead of actual time). I've now uploaded a corrected version:
http://people.debian.org/~fjp/tmp/kernel/congestion.pdf

I've also uploaded a second version that shows cumulative delay per type,
which probably gives a better insight:
http://people.debian.org/~fjp/tmp/kernel/congestion2.pdf

For both the top chart is without the revert, the bottom one after the
revert.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/