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