[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200911052114.36718.elendil@planet.nl>
Date: Thu, 5 Nov 2009 21:14:32 +0100
From: Frans Pop <elendil@...net.nl>
To: Mel Gorman <mel@....ul.ie>
Cc: Chris Mason <chris.mason@...cle.com>,
David Rientjes <rientjes@...gle.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Pekka Enberg <penberg@...helsinki.fi>,
Reinette Chatre <reinette.chatre@...el.com>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Karol Lewandowski <karol.k.lewandowski@...il.com>,
Mohamed Abbas <mohamed.abbas@...el.com>,
Jens Axboe <jens.axboe@...cle.com>,
"John W. Linville" <linville@...driver.com>, linux-mm@...ck.org
Subject: Re: [Bug #14141] order 2 page allocation failures in iwlagn
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists