From: Frans Pop <elendil@planet.nl>
To: Mel Gorman <mel@csn.ul.ie>
Subject: Re: [Bug #14141] order 2 page allocation failures in iwlagn
Date: Mon, 12 Oct 2009 19:32:11 +0200
User-Agent: KMail/1.9.9
Cc: David Rientjes <rientjes@google.com>,
       KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
       "Rafael J. Wysocki" <rjw@sisk.pl>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Kernel Testers List <kernel-testers@vger.kernel.org>,
       Pekka Enberg <penberg@cs.helsinki.fi>,
       Reinette Chatre <reinette.chatre@intel.com>,
       Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
       Karol Lewandowski <karol.k.lewandowski@gmail.com>,
       Mohamed Abbas <mohamed.abbas@intel.com>,
       "John W. Linville" <linville@tuxdriver.com>, linux-mm@kvack.org
References: <3onW63eFtRF.A.xXH.oMTxKB@chimera> <200910120110.28061.elendil@planet.nl> <20091012134328.GB8200@csn.ul.ie>
In-Reply-To: <20091012134328.GB8200@csn.ul.ie>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200910121932.14607.elendil@planet.nl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3764
Lines: 77

On Monday 12 October 2009, Mel Gorman wrote:
> Maybe. Your commit id's are different to what I see. Maybe it's because
> your tree has been shuffled around a bit

No, the commit IDs should be identical. My tree is just plain mainline.

Just to make sure... You did remove the "g" from the IDs, right?
So v2.6.30-rc6-1103-gb1bc81a becomes 'b1bc81a' and if you do
'git describe b1bc81a' you really should end up with the same IDs I have.

> but after some digging around in this general area, I saw this patch
>
> 4752c93c30 iwlcore: Allow skb allocation from tasklet

That is v2.6.30-rc6-773-g4752c93, which is part of the first wireless
merge I tested and where I saw no issues. But see below.

> This patch increases the number of GFP_ATOMIC allocations that can occur
> by allocating GFP_ATOMIC in some cases and GFP_KERNEL in others.
> Previously, only GFP_KERNEL was used and I didn't realise this
> allocation method was so recent. Problems of this sort have cropped up
> before and while there are later changes that suppress some of these
> warnings, I believe this is a strong candidate for where the allocation
> failures started appearing.
>
> > v2.6.30-rc6-1032-g7ba10a8       mac80211: fix transposed min/max CW values
> >     1.13    -
> >     This is a bugfix for aa837ee1d from an earlier merge! Could this maybe

There's a typo here. That ID should be: aa837e1d.

> >     influence the test results in between? There are various SKB related
> >     changes there, for example: dfbf97f3..e5b9215e.
> > v2.6.30-rc6-1037-g2c5b9e5	wireless: libertas: fix unaligned accesses
> > 	1.12    +-
> > v2.6.30-rc6-1044-g729e9c7	cfg80211: fix for duplicate userspace replies
> >     1.10    +- 
> > v2.6.30-rc6-1075-gc587de0	iwlwifi: unify station management
> >     1.9     ++-|+-
> > v2.6.30-rc6-1076-gd14d444	iwl3945: port allow skb allocation in tasklet
> >     I thought this was a prime candidate, but as you can see 
> >     several commits before failed too. Still worth looking at I think!
>
> Your commit IDs are different to what I see but it's the commit merge at
> b1bc81a0ef86b86fa410dd303d84c8c7bd09a64d. I agree that the last commit
> (d14d44407b9f06e3cf967fcef28ccb780caf0583) could make the problem worse
> because it expands the use of GFP_ATOMIC for another driver.

No, that was a mistake of mine. d14d444 is in a driver I don't even compile.
The one you identified (which is the same change for iwlagn) is much more
interesting.

I really do think that v2.6.30-rc6-1032-g7ba10a8 could play a role here.
That's a fix for v2.6.30-rc1-1131-gaa837e1. So that bug was introduced
_before_ the merge 82d0481 and may thus well explain both the latencies I
saw _and_ why that merge tested without problems. And that would also go a
long way to explain my test results.
So I'm going to retest 82d0481 with 7ba10a8 cherry-picked on top.

> > BISECTION of akpm (mm) MERGE
> > ----------------------------
[...]
> While I didn't spot anything too out of the ordinary here, they did
> occur shortly after a number of other page allocator related patches. 
> One small thing I noticed there is that kswapd is getting woken up less
> now than it did previously. Generally, I wouldn't have expected it to
> make a difference but it's possible that kswapd is not being woken up to
> reclaim at a higher order than it was previously. I have a patch for
> this below. It'd be nice if you could apply it and see do fewer
> allocation failures occur on current mainline.

I'll give that patch a try and report back.
--
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/