Re: [Bug #14141] order 2 page allocation failures in iwlagn
From: Frans Pop
Date: Wed Oct 14 2009 - 14:36:36 EST
Some initial results; all negative I'm afraid.
On Wednesday 14 October 2009, Mel Gorman wrote:
> This is what I found. The following were the possible commits that might
> be causing the problem.
> 56e49d2..f166777 -- reclaim
> I would have considered this strong candidates except again, the
> last good commit happened after this point. If other obvious
> candidates don't crop up, it might be worth double checking
> within this range, particularly commit 56e49d2 vmscan: evict
> use-once pages first as it is targeted at streaming-IO workloads
> which would include your music workload.
Reverted 56e49d2 on top of .31.1; no change.
> 5c87ead..e9bb35d -- inactive ratio changes
> These patches should be harmless but just in case, please
> compare the output of
> # grep inactive_ratio /proc/zoneinfo
> on 2.6.30 and 2.6.31 and make sure the ratios are the same.
The same for both (and for .32). DMA: 1; DMA32: 3
> Commit b70d94e altered how zonelists were selected during
> allocation. This was tested fairly heavily but if the testing
> missed something, it would mean that some allocations are not
> using the zones they should be.
Reverted on top of .31.1; no change.
> Commit bc75d33 is totally harmless but it mentions
> min_free_kbytes. I checked on my machine to make sure
> min_free_kbytes was the same on both 2.6.30 and 2.6.31. Can you
> check that this is true for your machine? If min_free_kbytes
> decreased, it could explain GFP_ATOMIC failures.
Virtually identical. .30: 5704; .31/.32: 5711
> After this point, your analysis indicates that things are already broken
> but lets look at some of the candidates anyway. Out of curiousity,
> was CONFIG_UNEVICTABLE_LRU unset in your .config for 2.6.30? I could
> only find your 2.6.31 .config. If it was, it might be worth reverting
> 6837765963f1723e80ca97b1fae660f3a60d77df and unsetting it in 2.6.31 and
> seeing what happens.
CONFIG_UNEVICTABLE_LRU was set and during bisections I've always accepted
the default, which was "y".
> Commit ee993b135ec75a93bd5c45e636bb210d2975159b altered how lumpy
> reclaim works but it should have been harmless. It does not cleanly
> revert but it's easy to manually revert.
Reverted on top of .31.1; no change.
I'll do some more digging in the 'akpm' merge.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/