++cc Nick on the right email address... --Ying On Mon, Apr 23, 2012 at 4:18 PM, Ying Han <yinghan@xxxxxxxxxx> wrote: > On Mon, Apr 23, 2012 at 3:20 PM, KOSAKI Motohiro > <kosaki.motohiro@xxxxxxxxxxxxxx> wrote: >> On Mon, Apr 23, 2012 at 4:56 PM, Ying Han <yinghan@xxxxxxxxxx> 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@xxxxxxxxxxxxxx> >>> 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@xxxxxxx> >>> 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@xxxxxxxxx. 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