Re: [RFC PATCH] do_try_to_free_pages() might enter infinite loop

[Ying Han <yinghan@google.com>]

On Mon, Apr 23, 2012 at 3:20 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> On Mon, Apr 23, 2012 at 4:56 PM, Ying Han <yinghan@google.com> wrote:
>> This is not a patch targeted to be merged at all, but trying to understand
>> a logic in global direct reclaim.
>>
>> There is a logic in global direct reclaim where reclaim fails on priority 0
>> and zone->all_unreclaimable is not set, it will cause the direct to start over
>> from DEF_PRIORITY. In some extreme cases, we've seen the system hang which is
>> very likely caused by direct reclaim enters infinite loop.
>>
>> There have been serious patches trying to fix similar issue and the latest
>> patch has good summary of all the efforts:
>>
>> 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
>>
>> Kosaki explained the problem triggered by async zone->all_unreclaimable and
>> zone->pages_scanned where the later one was being checked by direct reclaim.
>> However, after the patch, the problem remains where the setting of
>> zone->all_unreclaimable is asynchronous with zone is actually reclaimable or not.
>>
>> The zone->all_unreclaimable flag is set by kswapd by checking zone->pages_scanned in
>> zone_reclaimable(). Is that possible to have zone->all_unreclaimable == false while
>> the zone is actually unreclaimable?
>>
>> 1. while kswapd in reclaim priority loop, someone frees a page on the zone. It
>> will end up resetting the pages_scanned.
>>
>> 2. kswapd is frozen for whatever reason. I noticed Kosaki's covered the
>> hibernation case by checking oom_killer_disabled, but not sure if that is
>> everything we need to worry about. The key point here is that direct reclaim
>> relies on a flag which is set by kswapd asynchronously, that doesn't sound safe.
>
> If kswapd was frozen except hibernation, why don't you add frozen
> check instead of
> hibernation check? And when and why is that happen?

I haven't tried to reproduce the issue, so everything is based on
eye-balling the code. The problem is that we have the potential
infinite loop in direct reclaim where it keeps trying as long as
!zone->all_unreclaimable.

The flag is only set by kswapd and it will skip setting the flag if
the following condition is true:

zone->pages_scanned < zone_reclaimable_pages(zone) * 6;

In a few-pages-on-lru condition, the zone->pages_scanned is easily
remains 0 and also it is reset to 0 everytime a page being freed.
Then, i will cause global direct reclaim entering infinite loop.


>
>
>>
>> Instead of keep fixing the problem, I am wondering why we have the logic
>> "not oom but keep trying reclaim w/ priority 0 reclaim failure" at the first place:
>>
>> Here is the patch introduced the logic initially:
>>
>> commit 408d85441cd5a9bd6bc851d677a10c605ed8db5f
>> Author: Nick Piggin <npiggin@suse.de>
>> Date:   Mon Sep 25 23:31:27 2006 -0700
>>
>>    [PATCH] oom: use unreclaimable info
>>
>> However, I didn't find detailed description of what problem the commit trying
>> to fix and wondering if the problem still exist after 5 years. I would be happy
>> to see the later case where we can consider to revert the initial patch.
>
> This patch fixed one of false oom issue. Think,
>
> 1. thread-a reach priority-0.
> 2. thread-b was exited and free a lot of pages.
> 3. thread-a call out_of_memory().
>
> This is not very good because we now have enough memory....

Isn't that being covered by the following in __alloc_pages_may_oom() ?

>-------/*
>------- * Go through the zonelist yet one more time, keep very high watermark
>------- * here, this is only to catch a parallel oom killing, we must fail if
>------- * we're still under heavy pressure.
>------- */
>-------page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask,
>------->-------order, zonelist, high_zoneidx,
>------->-------ALLOC_WMARK_HIGH|ALLOC_CPUSET,
>------->-------preferred_zone, migratetype);

Thanks

--Ying

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>