RE: Possible deadloop in direct reclaim?

[Lisa Du <cldu@marvell.com>]

Dear Kosaki
   Would you please help to check my comment as below:
>(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
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>