Messages in this thread | | | Date | Mon, 2 Nov 2015 10:53:35 +0100 | From | Michal Hocko <> | Subject | Re: [lkp] [mm, page_alloc] 43993977ba: +88% OOM possibility |
| |
On Mon 02-11-15 16:55:15, Huang, Ying wrote: > Michal Hocko <mhocko@kernel.org> 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
| |