diff for duplicates of <20110609183637.GC20333@cmpxchg.org> diff --git a/a/1.txt b/N1/1.txt index dc84911..faab28b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,19 +4,19 @@ On Thu, Jun 09, 2011 at 10:36:47AM -0700, Ying Han wrote: > >> On Wed, Jun 8, 2011 at 8:32 AM, Johannes Weiner <hannes@cmpxchg.org> wrote: > >> > I guess it would make much more sense to evaluate if reclaiming from > >> > memcgs while there are others exceeding their soft limit is even a -> >> > problem. Otherwise this discussion is pretty pointless. +> >> > problem. Otherwise this discussion is pretty pointless. > >> > >> AFAIK it is a problem since it changes the spec of kernel API > >> memory.soft_limit_in_bytes. That value is set per-memcg which all the > >> pages allocated above that are best effort and targeted to reclaim > >> prior to others. > > -> > That's not really true. Quoting the documentation: +> > That's not really true. Quoting the documentation: > > -> > When the system detects memory contention or low memory, control groups -> > are pushed back to their soft limits. If the soft limit of each control -> > group is very high, they are pushed back as much as possible to make -> > sure that one control group does not starve the others of memory. +> > When the system detects memory contention or low memory, control groups +> > are pushed back to their soft limits. If the soft limit of each control +> > group is very high, they are pushed back as much as possible to make +> > sure that one control group does not starve the others of memory. > > > > I am language lawyering here, but I don't think it says it won't touch > > other memcgs at all while there are memcgs exceeding their soft limit. @@ -72,12 +72,12 @@ soft limit implementation, as far as I understood. > > It would be a lie about the current code in the first place, which > > does soft limit reclaim and then regular reclaim, no matter the -> > outcome of the soft limit reclaim cycle. It will go for the soft +> > outcome of the soft limit reclaim cycle. It will go for the soft > > limit first, but after an allocation under pressure the VM is likely > > to have reclaimed from other memcgs as well. > > > > I saw your patch to fix that and break out of reclaim if soft limit -> > reclaim did enough. But this fix is not much newer than my changes. +> > reclaim did enough. But this fix is not much newer than my changes. > > My soft_limit patch was developed in parallel with your patchset, and > most of that wouldn't apply here. @@ -88,17 +88,17 @@ it only now, so we are not really breaking backward compatibility. > > The second part of this is: > > -> > Please note that soft limits is a best effort feature, it comes with -> > no guarantees, but it does its best to make sure that when memory is -> > heavily contended for, memory is allocated based on the soft limit -> > hints/setup. Currently soft limit based reclaim is setup such that -> > it gets invoked from balance_pgdat (kswapd). +> > Please note that soft limits is a best effort feature, it comes with +> > no guarantees, but it does its best to make sure that when memory is +> > heavily contended for, memory is allocated based on the soft limit +> > hints/setup. Currently soft limit based reclaim is setup such that +> > it gets invoked from balance_pgdat (kswapd). > > We had patch merged which add the soft_limit reclaim also in the global ttfp. > > memcg-add-the-soft_limit-reclaim-in-global-direct-reclaim.patch > -> > It's not the pages-over-soft-limit that are best effort. It says that +> > It's not the pages-over-soft-limit that are best effort. It says that > > it tries its best to take soft limits into account while reclaiming. > Hmm. Both cases are true. The best effort pages I referring to means > "the page above the soft_limit are targeted to reclaim first under @@ -118,7 +118,7 @@ breaks existing users in that regard. > > currently made in the documentation. > > > > But much more important than keeping documentation promises is not to -> > break actual users. So if you are yourself a user of soft limits, +> > break actual users. So if you are yourself a user of soft limits, > > test the new code pretty please and complain if it breaks your setup! > > Yes, I've been running tests on your patchset, but not getting into @@ -159,3 +159,10 @@ there is clean cache around): While it would be sufficient to reclaim only from A, actually reclaiming from B and C is not a big deal in practice, I would suspect. + +-- +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 1e74564..446e951 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -34,19 +34,19 @@ "> >> On Wed, Jun 8, 2011 at 8:32 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:\n" "> >> > I guess it would make much more sense to evaluate if reclaiming from\n" "> >> > memcgs while there are others exceeding their soft limit is even a\n" - "> >> > problem. \302\240Otherwise this discussion is pretty pointless.\n" + "> >> > problem. Otherwise this discussion is pretty pointless.\n" "> >>\n" "> >> AFAIK it is a problem since it changes the spec of kernel API\n" "> >> memory.soft_limit_in_bytes. That value is set per-memcg which all the\n" "> >> pages allocated above that are best effort and targeted to reclaim\n" "> >> prior to others.\n" "> >\n" - "> > That's not really true. \302\240Quoting the documentation:\n" + "> > That's not really true. Quoting the documentation:\n" "> >\n" - "> > \302\240 \302\240When the system detects memory contention or low memory, control groups\n" - "> > \302\240 \302\240are pushed back to their soft limits. If the soft limit of each control\n" - "> > \302\240 \302\240group is very high, they are pushed back as much as possible to make\n" - "> > \302\240 \302\240sure that one control group does not starve the others of memory.\n" + "> > When the system detects memory contention or low memory, control groups\n" + "> > are pushed back to their soft limits. If the soft limit of each control\n" + "> > group is very high, they are pushed back as much as possible to make\n" + "> > sure that one control group does not starve the others of memory.\n" "> >\n" "> > I am language lawyering here, but I don't think it says it won't touch\n" "> > other memcgs at all while there are memcgs exceeding their soft limit.\n" @@ -102,12 +102,12 @@ "\n" "> > It would be a lie about the current code in the first place, which\n" "> > does soft limit reclaim and then regular reclaim, no matter the\n" - "> > outcome of the soft limit reclaim cycle. \302\240It will go for the soft\n" + "> > outcome of the soft limit reclaim cycle. It will go for the soft\n" "> > limit first, but after an allocation under pressure the VM is likely\n" "> > to have reclaimed from other memcgs as well.\n" "> >\n" "> > I saw your patch to fix that and break out of reclaim if soft limit\n" - "> > reclaim did enough. \302\240But this fix is not much newer than my changes.\n" + "> > reclaim did enough. But this fix is not much newer than my changes.\n" "> \n" "> My soft_limit patch was developed in parallel with your patchset, and\n" "> most of that wouldn't apply here.\n" @@ -118,17 +118,17 @@ "\n" "> > The second part of this is:\n" "> >\n" - "> > \302\240 \302\240Please note that soft limits is a best effort feature, it comes with\n" - "> > \302\240 \302\240no guarantees, but it does its best to make sure that when memory is\n" - "> > \302\240 \302\240heavily contended for, memory is allocated based on the soft limit\n" - "> > \302\240 \302\240hints/setup. Currently soft limit based reclaim is setup such that\n" - "> > \302\240 \302\240it gets invoked from balance_pgdat (kswapd).\n" + "> > Please note that soft limits is a best effort feature, it comes with\n" + "> > no guarantees, but it does its best to make sure that when memory is\n" + "> > heavily contended for, memory is allocated based on the soft limit\n" + "> > hints/setup. Currently soft limit based reclaim is setup such that\n" + "> > it gets invoked from balance_pgdat (kswapd).\n" "> \n" "> We had patch merged which add the soft_limit reclaim also in the global ttfp.\n" "> \n" "> memcg-add-the-soft_limit-reclaim-in-global-direct-reclaim.patch\n" "> \n" - "> > It's not the pages-over-soft-limit that are best effort. \302\240It says that\n" + "> > It's not the pages-over-soft-limit that are best effort. It says that\n" "> > it tries its best to take soft limits into account while reclaiming.\n" "> Hmm. Both cases are true. The best effort pages I referring to means\n" "> \"the page above the soft_limit are targeted to reclaim first under\n" @@ -148,7 +148,7 @@ "> > currently made in the documentation.\n" "> >\n" "> > But much more important than keeping documentation promises is not to\n" - "> > break actual users. \302\240So if you are yourself a user of soft limits,\n" + "> > break actual users. So if you are yourself a user of soft limits,\n" "> > test the new code pretty please and complain if it breaks your setup!\n" "> \n" "> Yes, I've been running tests on your patchset, but not getting into\n" @@ -188,6 +188,13 @@ "\n" "While it would be sufficient to reclaim only from A, actually\n" "reclaiming from B and C is not a big deal in practice, I would\n" - suspect. + "suspect.\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>" -0ee3eaa0da7a0e24dc2dc51e3ec063bf55a7f77c267b6ddb59aa25eb310b1755 +9f7a14964577a3192558fa3e602aa7e5a7fe3b6270ec784a341c3c857bf8bc88
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.