diff for duplicates of <20110517103840.GL5279@suse.de> diff --git a/a/1.txt b/N1/1.txt index b4abfb0..5f2a833 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -206,10 +206,3 @@ series and Minchan's patch below? Thanks. -- Mel Gorman SUSE Labs - --- -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> diff --git a/a/content_digest b/N1/content_digest index 4aed393..e4707ca 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -235,13 +235,6 @@ "\n" "-- \n" "Mel Gorman\n" - "SUSE Labs\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + SUSE Labs -c94e230369de28508d2e3814ca7cc4d5b22c3bc05b8d7aaa85953f7a6328e426 +718b88905ad14a68d9ed1394b7e520d6901d1d35aa03bda73b2e364715398181
diff --git a/a/1.txt b/N2/1.txt index b4abfb0..14d10d0 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -13,27 +13,27 @@ On Tue, May 17, 2011 at 08:50:44AM +0900, Minchan Kim wrote: > >> >> >> > > >> >> >> > Signed-off-by: Mel Gorman<mgorman@suse.de> > >> >> >> > --- -> >> >> >> > mm/vmscan.c | 4 ++++ -> >> >> >> > 1 files changed, 4 insertions(+), 0 deletions(-) +> >> >> >> > mm/vmscan.c | 4 ++++ +> >> >> >> > 1 files changed, 4 insertions(+), 0 deletions(-) > >> >> >> > > >> >> >> > diff --git a/mm/vmscan.c b/mm/vmscan.c > >> >> >> > index af24d1e..4d24828 100644 > >> >> >> > --- a/mm/vmscan.c > >> >> >> > +++ b/mm/vmscan.c > >> >> >> > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining, -> >> >> >> > unsigned long balanced = 0; -> >> >> >> > bool all_zones_ok = true; +> >> >> >> > unsigned long balanced = 0; +> >> >> >> > bool all_zones_ok = true; > >> >> >> > -> >> >> >> > + /* If kswapd has been running too long, just sleep */ -> >> >> >> > + if (need_resched()) -> >> >> >> > + return false; +> >> >> >> > + /* If kswapd has been running too long, just sleep */ +> >> >> >> > + if (need_resched()) +> >> >> >> > + return false; > >> >> >> > + > >> >> >> > >> >> >> Hmm... I don't like this patch so much. because this code does > >> >> >> > >> >> >> - don't sleep if kswapd got context switch at shrink_inactive_list > >> >> > -> >> >> > This isn't entirely true: need_resched() will be false, so we'll follow +> >> >> > This isn't entirely true: need_resched() will be false, so we'll follow > >> >> > the normal path for determining whether to sleep or not, in effect > >> >> > leaving the current behaviour unchanged. > >> >> > @@ -42,16 +42,16 @@ On Tue, May 17, 2011 at 08:50:44AM +0900, Minchan Kim wrote: > >> >> > This also isn't entirely true: whether need_resched() is true at this > >> >> > point depends on a whole lot more that whether we did a context switch > >> >> > in shrink_inactive. It mostly depends on how long we've been running -> >> >> > without giving up the CPU. Generally that will mean we've been round +> >> >> > without giving up the CPU. Generally that will mean we've been round > >> >> > the shrinker loop hundreds to thousands of times without sleeping. > >> >> > > >> >> >> It seems to be semi random behavior. > >> >> > -> >> >> > Well, we have to do something. Chris Mason first suspected the hang was -> >> >> > a kswapd rescheduling problem a while ago. We tried putting +> >> >> > Well, we have to do something. Chris Mason first suspected the hang was +> >> >> > a kswapd rescheduling problem a while ago. We tried putting > >> >> > cond_rescheds() in several places in the vmscan code, but to no avail. > >> >> -> >> >> Is it a result of test with patch of Hannes(ie, !pgdat_balanced)? +> >> >> Is it a result of test with patch of Hannes(ie, !pgdat_balanced)? > >> >> > >> >> If it isn't, it would be nop regardless of putting cond_reshed at vmscan.c. > >> >> Because, although we complete zone balancing, kswapd doesn't sleep as @@ -65,7 +65,7 @@ On Tue, May 17, 2011 at 08:50:44AM +0900, Minchan Kim wrote: > >> >> kswapd consumes CPU a lot. > >> >> > >> >> > The need_resched() in sleeping_prematurely() seems to be about the best -> >> >> > option. The other option might be just to put a cond_resched() in +> >> >> > option. The other option might be just to put a cond_resched() in > >> >> > kswapd_try_to_sleep(), but that will really have about the same effect. > >> >> > >> >> I don't oppose it but before that, I think we have to know why kswapd @@ -87,18 +87,18 @@ On Tue, May 17, 2011 at 08:50:44AM +0900, Minchan Kim wrote: > > Lets see; > > > > shrink_page_list() only applies if inactive pages were isolated -> > which in turn may not happen if all_unreclaimable is set in -> > shrink_zones(). If for whatver reason, all_unreclaimable is -> > set on all zones, we can miss calling cond_resched(). +> > which in turn may not happen if all_unreclaimable is set in +> > shrink_zones(). If for whatver reason, all_unreclaimable is +> > set on all zones, we can miss calling cond_resched(). > > > > shrink_slab only applies if we are reclaiming slab pages. If the first -> > shrinker returns -1, we do not call cond_resched(). If that -> > first shrinker is dcache and __GFP_FS is not set, direct -> > reclaimers will not shrink at all. However, if there are -> > enough of them running or if one of the other shrinkers -> > is running for a very long time, kswapd could be starved -> > acquiring the shrinker_rwsem and never reaching the -> > cond_resched(). +> > shrinker returns -1, we do not call cond_resched(). If that +> > first shrinker is dcache and __GFP_FS is not set, direct +> > reclaimers will not shrink at all. However, if there are +> > enough of them running or if one of the other shrinkers +> > is running for a very long time, kswapd could be starved +> > acquiring the shrinker_rwsem and never reaching the +> > cond_resched(). > > Don't we have to move cond_resched? > @@ -143,12 +143,12 @@ between shrinkers and still consume a lot of CPU. > > > > balance_pgdat() only calls cond_resched if the zones are not -> > balanced. For a high-order allocation that is balanced, it -> > checks order-0 again. During that window, order-0 might have -> > become unbalanced so it loops again for order-0 and returns -> > that was reclaiming for order-0 to kswapd(). It can then find -> > that a caller has rewoken kswapd for a high-order and re-enters -> > balance_pgdat() without ever have called cond_resched(). +> > balanced. For a high-order allocation that is balanced, it +> > checks order-0 again. During that window, order-0 might have +> > become unbalanced so it loops again for order-0 and returns +> > that was reclaiming for order-0 to kswapd(). It can then find +> > that a caller has rewoken kswapd for a high-order and re-enters +> > balance_pgdat() without ever have called cond_resched(). > > If kswapd reclaims order-o followed by high order, it would have a > chance to call cond_resched in shrink_page_list. But if all zones are diff --git a/a/content_digest b/N2/content_digest index 4aed393..ab42aa3 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -43,27 +43,27 @@ "> >> >> >> >\n" "> >> >> >> > Signed-off-by: Mel Gorman<mgorman@suse.de>\n" "> >> >> >> > ---\n" - "> >> >> >> > \302\240 mm/vmscan.c | \302\240 \302\2404 ++++\n" - "> >> >> >> > \302\240 1 files changed, 4 insertions(+), 0 deletions(-)\n" + "> >> >> >> > mm/vmscan.c | 4 ++++\n" + "> >> >> >> > 1 files changed, 4 insertions(+), 0 deletions(-)\n" "> >> >> >> >\n" "> >> >> >> > diff --git a/mm/vmscan.c b/mm/vmscan.c\n" "> >> >> >> > index af24d1e..4d24828 100644\n" "> >> >> >> > --- a/mm/vmscan.c\n" "> >> >> >> > +++ b/mm/vmscan.c\n" "> >> >> >> > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,\n" - "> >> >> >> > \302\240 \302\240 unsigned long balanced = 0;\n" - "> >> >> >> > \302\240 \302\240 bool all_zones_ok = true;\n" + "> >> >> >> > unsigned long balanced = 0;\n" + "> >> >> >> > bool all_zones_ok = true;\n" "> >> >> >> >\n" - "> >> >> >> > + \302\240 /* If kswapd has been running too long, just sleep */\n" - "> >> >> >> > + \302\240 if (need_resched())\n" - "> >> >> >> > + \302\240 \302\240 \302\240 \302\240 \302\240 return false;\n" + "> >> >> >> > + /* If kswapd has been running too long, just sleep */\n" + "> >> >> >> > + if (need_resched())\n" + "> >> >> >> > + return false;\n" "> >> >> >> > +\n" "> >> >> >>\n" "> >> >> >> Hmm... I don't like this patch so much. because this code does\n" "> >> >> >>\n" "> >> >> >> - don't sleep if kswapd got context switch at shrink_inactive_list\n" "> >> >> >\n" - "> >> >> > This isn't entirely true: \302\240need_resched() will be false, so we'll follow\n" + "> >> >> > This isn't entirely true: need_resched() will be false, so we'll follow\n" "> >> >> > the normal path for determining whether to sleep or not, in effect\n" "> >> >> > leaving the current behaviour unchanged.\n" "> >> >> >\n" @@ -72,16 +72,16 @@ "> >> >> > This also isn't entirely true: whether need_resched() is true at this\n" "> >> >> > point depends on a whole lot more that whether we did a context switch\n" "> >> >> > in shrink_inactive. It mostly depends on how long we've been running\n" - "> >> >> > without giving up the CPU. \302\240Generally that will mean we've been round\n" + "> >> >> > without giving up the CPU. Generally that will mean we've been round\n" "> >> >> > the shrinker loop hundreds to thousands of times without sleeping.\n" "> >> >> >\n" "> >> >> >> It seems to be semi random behavior.\n" "> >> >> >\n" - "> >> >> > Well, we have to do something. \302\240Chris Mason first suspected the hang was\n" - "> >> >> > a kswapd rescheduling problem a while ago. \302\240We tried putting\n" + "> >> >> > Well, we have to do something. Chris Mason first suspected the hang was\n" + "> >> >> > a kswapd rescheduling problem a while ago. We tried putting\n" "> >> >> > cond_rescheds() in several places in the vmscan code, but to no avail.\n" "> >> >>\n" - "> >> >> Is it a result of \302\240test with patch of Hannes(ie, !pgdat_balanced)?\n" + "> >> >> Is it a result of test with patch of Hannes(ie, !pgdat_balanced)?\n" "> >> >>\n" "> >> >> If it isn't, it would be nop regardless of putting cond_reshed at vmscan.c.\n" "> >> >> Because, although we complete zone balancing, kswapd doesn't sleep as\n" @@ -95,7 +95,7 @@ "> >> >> kswapd consumes CPU a lot.\n" "> >> >>\n" "> >> >> > The need_resched() in sleeping_prematurely() seems to be about the best\n" - "> >> >> > option. \302\240The other option might be just to put a cond_resched() in\n" + "> >> >> > option. The other option might be just to put a cond_resched() in\n" "> >> >> > kswapd_try_to_sleep(), but that will really have about the same effect.\n" "> >> >>\n" "> >> >> I don't oppose it but before that, I think we have to know why kswapd\n" @@ -117,18 +117,18 @@ "> > Lets see;\n" "> >\n" "> > shrink_page_list() only applies if inactive pages were isolated\n" - "> > \302\240 \302\240 \302\240 \302\240which in turn may not happen if all_unreclaimable is set in\n" - "> > \302\240 \302\240 \302\240 \302\240shrink_zones(). If for whatver reason, all_unreclaimable is\n" - "> > \302\240 \302\240 \302\240 \302\240set on all zones, we can miss calling cond_resched().\n" + "> > which in turn may not happen if all_unreclaimable is set in\n" + "> > shrink_zones(). If for whatver reason, all_unreclaimable is\n" + "> > set on all zones, we can miss calling cond_resched().\n" "> >\n" "> > shrink_slab only applies if we are reclaiming slab pages. If the first\n" - "> > \302\240 \302\240 \302\240 \302\240shrinker returns -1, we do not call cond_resched(). If that\n" - "> > \302\240 \302\240 \302\240 \302\240first shrinker is dcache and __GFP_FS is not set, direct\n" - "> > \302\240 \302\240 \302\240 \302\240reclaimers will not shrink at all. However, if there are\n" - "> > \302\240 \302\240 \302\240 \302\240enough of them running or if one of the other shrinkers\n" - "> > \302\240 \302\240 \302\240 \302\240is running for a very long time, kswapd could be starved\n" - "> > \302\240 \302\240 \302\240 \302\240acquiring the shrinker_rwsem and never reaching the\n" - "> > \302\240 \302\240 \302\240 \302\240cond_resched().\n" + "> > shrinker returns -1, we do not call cond_resched(). If that\n" + "> > first shrinker is dcache and __GFP_FS is not set, direct\n" + "> > reclaimers will not shrink at all. However, if there are\n" + "> > enough of them running or if one of the other shrinkers\n" + "> > is running for a very long time, kswapd could be starved\n" + "> > acquiring the shrinker_rwsem and never reaching the\n" + "> > cond_resched().\n" "> \n" "> Don't we have to move cond_resched?\n" "> \n" @@ -173,12 +173,12 @@ "\n" "> >\n" "> > balance_pgdat() only calls cond_resched if the zones are not\n" - "> > \302\240 \302\240 \302\240 \302\240balanced. For a high-order allocation that is balanced, it\n" - "> > \302\240 \302\240 \302\240 \302\240checks order-0 again. During that window, order-0 might have\n" - "> > \302\240 \302\240 \302\240 \302\240become unbalanced so it loops again for order-0 and returns\n" - "> > \302\240 \302\240 \302\240 \302\240that was reclaiming for order-0 to kswapd(). It can then find\n" - "> > \302\240 \302\240 \302\240 \302\240that a caller has rewoken kswapd for a high-order and re-enters\n" - "> > \302\240 \302\240 \302\240 \302\240balance_pgdat() without ever have called cond_resched().\n" + "> > balanced. For a high-order allocation that is balanced, it\n" + "> > checks order-0 again. During that window, order-0 might have\n" + "> > become unbalanced so it loops again for order-0 and returns\n" + "> > that was reclaiming for order-0 to kswapd(). It can then find\n" + "> > that a caller has rewoken kswapd for a high-order and re-enters\n" + "> > balance_pgdat() without ever have called cond_resched().\n" "> \n" "> If kswapd reclaims order-o followed by high order, it would have a\n" "> chance to call cond_resched in shrink_page_list. But if all zones are\n" @@ -244,4 +244,4 @@ "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -c94e230369de28508d2e3814ca7cc4d5b22c3bc05b8d7aaa85953f7a6328e426 +7b70b42fd87f40a3b8478f3e5abad833293dba1c7735ecbbef378536f1b26a78
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.