Re: [Bug #14141] order 2 page allocation failures in iwlagn

[Mel Gorman]

On Mon, Oct 05, 2009 at 05:04:55PM -0700, David Rientjes wrote:
> On Mon, 5 Oct 2009, Frans Pop wrote:
> 
> > And the winner is:
> > 2ff05b2b4eac2e63d345fc731ea151a060247f53 is first bad commit
> > commit 2ff05b2b4eac2e63d345fc731ea151a060247f53
> > Author: David Rientjes <rientjes@xxxxxxxxxx>
> > Date:   Tue Jun 16 15:32:56 2009 -0700
> > 
> >     oom: move oom_adj value from task_struct to mm_struct
> > 
> > I'm confident that the bisection is good. The test case was very reliable 
> > while zooming in on the merge from akpm.
> > 
> 
> I doubt it for two reasons: (i) this commit was reverted in 0753ba0 since 
> 2.6.31-rc7 and is no longer in the kernel, and (ii) these are GFP_ATOMIC 
> allocations which would be unaffected by oom killer scores.
> 

However, the problem was reported to start showing up in 2.6.31-rc1 so
while it might not be *the* patch, it might be making the type of change
that caused more fragmentation. This patch adjusted the size of
mm_struct and maybe it was enough to change the "order" required for the
slab. Maybe there are other slabs that have changed size as well in that
timeframe.

Frans, what is the size of mm_struct before and after this patch was
applied? Find it with either

grep mm_struct /proc/slabinfo

and if the information is not available there, try

cat /sys/kernel/slab/mm_struct/slab_size and
/sys/kernel/slab/mm_struct/order

Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/