Re: iwlagn: order 2 page allocation failures

[Mel Gorman]

On Tue, Sep 08, 2009 at 09:59:05AM -0500, Larry Finger wrote:
> John W. Linville wrote:
> > On Tue, Sep 08, 2009 at 02:11:35PM +0300, Pekka Enberg wrote:
> >> On Tue, Sep 8, 2009 at 1:54 PM, Mel Gorman<mel@xxxxxxxxx> wrote:
> >>> My feeling is also that a number of these page allocation failures have
> >>> been related to wireless drivers. Is that accurate? If so, have there
> >>> been changes made to the wireless stack in this cycle that would have
> >>> increased the order of pages allocated?
> >> That's my general feeling as well. We have linux-wireless CC'd so
> >> maybe this rings a bell for them.
> > 
> > AFAIK, this is only the second separate report.  The other related
> > to ipw2200, which actually shares no code with the iwlagn driver and
> > is not based on the mac80211 stack.
> 
> A previous issue concerned the interaction between wireless and SLUB
> debugging that caused O(0) allocations to get bumped to O(1), but that

Ok, but now they are getting bumped to order-2 because that is the allocation
failure that's happening here. That's pretty risky for a __GFP_HIGH|__GFP_COMP
allocation - i.e. high-priority and atomic allocation.

> was not relevant to this case either. I'm not aware of any other page
> allocation problems with wireless.
> 

Are atomic order-2 allocations really expected in wireless or has something
else changed recently? Other than slub-debug, what options have been
recently added that can push kmalloc() requests up slightly and possible
make an order-1 allocation an order-2? If it's not in wireless, has there
been additional padding added to skbuffs in the networking layer that might
have pushed an allocation over an order-1 boundary increasing the size of
the allocation to order-2?

The reporter says that the machine grinds for a bit and recovers which
is consistent with kswapd kicking in to reclaim the contiguous pages but
it's hardly desirable.

Franz, in the full dmesg was there any mention of "SLUB: Unable to allocate
memory on node"? If so, could you post the contents of that as well because
it should tell us more about the slab allocation that failed which vaguely
looks like the path that went splat. Also, did you have any slub debug
options enabled on the command line?

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/