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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
