Re: Possible deadloop in direct reclaim?

[KOSAKI Motohiro <kosaki.motohiro@gmail.com>]

(7/31/13 10:24 PM), Lisa Du wrote:
> 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?

Sorry I don't understand what "this" mean. I mean, Even though you use desktop or server machine, no compaction kernel
easily makes no order-2 situations.
Then, our in-kernel subsystems don't use order-2 allocations as far as possible.


> 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?

???
fork alloc order-1 memory for stack. Where and why alloc order-2? If it is arch specific code, please
contact arch maintainer.



>>
>>>      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:

Please read more older code. Your pointed code is temporary change and I changed back for fixing
bugs.
If you look at the status in middle direct reclaim, we can't avoid race condition from multi direct
reclaim issues. Moreover, if kswapd doesn't awaken, it is a problem. This is a reason why current code
behave as you described.
I agree we should fix your issue as far as possible. But I can't agree your analysis.

--
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>