RE: Possible deadloop in direct reclaim?

[Lisa Du <cldu@marvell.com>]

-----Original Message-----
From: KOSAKI Motohiro [mailto:kosaki.motohiro@gmail.com] 
Sent: 2013年7月30日 0:44
To: Lisa Du
Cc: KOSAKI Motohiro; Christoph Lameter; linux-mm@kvack.org; 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@jp.fujitsu.com>
Date:   Thu Apr 14 15:22:12 2011 -0700

    vmscan: all_unreclaimable() use zone->all_unreclaimable as a name