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