-----Original Message----- From: KOSAKI Motohiro [mailto:kosaki.motohiro@xxxxxxxxx] Sent: 2013年7月30日 0:44 To: Lisa Du Cc: KOSAKI Motohiro; Christoph Lameter; linux-mm@xxxxxxxxx; Mel Gorman; Bob Liu Subject: Re: Possible deadloop in direct reclaim? (7/25/13 9:11 PM), Lisa Du wrote: > Dear KOSAKI > In my test, I didn't set compaction. Maybe compaction is helpful to avoid this issue. I can have try later. > In my mind CONFIG_COMPACTION is an optional configuration right? Right. But if you don't set it, application must NOT use >1 order allocations. It doesn't work and it is expected result. That's your application mistake. Dear Kosaki, I have two questions on your explanation: a) you said if don't set CONFIG_COMPATION, application must NOT use >1 order allocations, is there any documentation for this theory? b) My order-2 allocation not comes from application, but from do_fork which is in kernel space, in my mind when a parent process forks a child process, it need to allocate a order-2 memory, if a) is right, then CONFIG_COMPATION should be a MUST configuration for linux kernel but not optional? > If we don't use, and met such an issue, how should we deal with such infinite loop? > > I made a change in all_reclaimable() function, passed overnight tests, please help review, thanks in advance! > @@ -2353,7 +2353,9 @@ static bool all_unreclaimable(struct zonelist *zonelist, > continue; > if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL)) > continue; > - if (!zone->all_unreclaimable) > + if (zone->all_unreclaimable) > + continue; > + if (zone_reclaimable(zone)) > return false; Please tell me why you chaned here. The original check is once found zone->all_unreclaimable is false, it will return false, then it will set did_some_progress non-zero. Then another loop of direct_reclaimed performed. But I think zone->all_unreclaimable is not always reliable such as in my case, kswapd go to sleep and no one will change this flag. We should also check zone_reclaimalbe(zone) if zone->all_unreclaimalbe = 0 to double confirm if a zone is reclaimable; This change also avoid the issue you described in below commit: commit 929bea7c714220fc76ce3f75bef9056477c28e74 Author: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> Date: Thu Apr 14 15:22:12 2011 -0700 vmscan: all_unreclaimable() use zone->all_unreclaimable as a name ?韬{.n???檩jg???a?旃???)钋???骅w+h?璀?ｙ/i?⒏??⒎???Щ ??m?? ?)钋???痂?^??觥??ザ?v???O璁?f??i?⒏?