On Mon 02-11-15 16:55:15, Huang, Ying wrote: > Michal Hocko <[email protected]> writes: [...] > > It would be interesting to see all the page allocation failure warnings > > (if they are different). Maybe other callers have relied on GFP_ATOMIC > > and access to memory reserves. The above path is not this case though. > > I take a look at all dmesgs, and found the backtrace for page allocation > failure is same for all. Is it possible that this commit cause more > memory were allocated or kept in memory so that more OOM were triggered?
I can imagine that some of the callers were not converted properly or missed and a lack of __GFP_KSWAPD_RECLAIM could indeed cause a later kswapd kick off. I am staring into the commit but nothing has jumped at me yet. Could you collect /proc/vmstat (snapshot every 1s) on both good and bad kernels. I expect the later would see a less scanning by kswapd. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
