diff for duplicates of <20110609233154.GA26745@cmpxchg.org> diff --git a/a/1.txt b/N1/1.txt index 4c75c16..397a7f0 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -6,19 +6,19 @@ On Thu, Jun 09, 2011 at 03:30:27PM -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. @@ -62,7 +62,7 @@ On Thu, Jun 09, 2011 at 03:30:27PM -0700, Ying Han wrote: > >> soft_limit) . > > > > I think the most important thing we wanted was to round-robin scan all -> > soft limit excessors instead of just the biggest one. I understood +> > soft limit excessors instead of just the biggest one. I understood > > this is the biggest fault with soft limits right now. > > > > We came up with maintaining a list of excessors, rather than a tree, @@ -74,12 +74,12 @@ On Thu, Jun 09, 2011 at 03:30:27PM -0700, Ying Han wrote: > > > >> > 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. @@ -90,23 +90,23 @@ On Thu, Jun 09, 2011 at 03:30:27PM -0700, Ying Han wrote: > > > >> > 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 > >> memory contention" > > -> > I really don't know where you are taking this from. That is neither +> > I really don't know where you are taking this from. That is neither > > documented anywhere, nor is it the current behaviour. > > I got the email from andrew on may 27 and you were on the cc-ed :) @@ -116,7 +116,7 @@ I wasn't asking about this patch at all... This is the conversation: Me: -> >> > 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. You: @@ -127,7 +127,7 @@ You: Me: -> > I really don't know where you are taking this from. That is neither +> > I really don't know where you are taking this from. That is neither > > documented anywhere, nor is it the current behaviour. And this is still my question. @@ -142,3 +142,10 @@ Please tell me exactly how my patch regresses existing behaviour, a user interface, a documented feature, etc. If you have an even better idea, please propose it. + +-- +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 3980673..2c0e2ac 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -36,19 +36,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" @@ -92,7 +92,7 @@ "> >> soft_limit) .\n" "> >\n" "> > I think the most important thing we wanted was to round-robin scan all\n" - "> > soft limit excessors instead of just the biggest one. \302\240I understood\n" + "> > soft limit excessors instead of just the biggest one. I understood\n" "> > this is the biggest fault with soft limits right now.\n" "> >\n" "> > We came up with maintaining a list of excessors, rather than a tree,\n" @@ -104,12 +104,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" @@ -120,23 +120,23 @@ "> >\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" "> >> memory contention\"\n" "> >\n" - "> > I really don't know where you are taking this from. \302\240That is neither\n" + "> > I really don't know where you are taking this from. That is neither\n" "> > documented anywhere, nor is it the current behaviour.\n" "> \n" "> I got the email from andrew on may 27 and you were on the cc-ed :)\n" @@ -146,7 +146,7 @@ "\n" "Me:\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" "\n" "You:\n" @@ -157,7 +157,7 @@ "\n" "Me:\n" "\n" - "> > I really don't know where you are taking this from. \302\240That is neither\n" + "> > I really don't know where you are taking this from. That is neither\n" "> > documented anywhere, nor is it the current behaviour.\n" "\n" "And this is still my question.\n" @@ -171,6 +171,13 @@ "Please tell me exactly how my patch regresses existing behaviour, a\n" "user interface, a documented feature, etc.\n" "\n" - If you have an even better idea, please propose it. + "If you have an even better idea, please propose it.\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>" -755ad89ec1c7e6a1579daa9ed3875acd6bf4360c6cfaea8c912565f50e7cc32d +7cfb09fc719523bd496b7f91e99273d0d3b09bba7aa7ff81b3ec7426928d0e7b
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.