diff for duplicates of <20110901082755.GD22561@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 47a897b..727fad8 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,16 +3,16 @@ On Thu, Sep 01, 2011 at 12:04:24AM -0700, Ying Han wrote: > > On Wed, Aug 31, 2011 at 11:05:51PM -0700, Ying Han wrote: > >> On Tue, Aug 30, 2011 at 1:42 AM, Johannes Weiner <jweiner@redhat.com> wrote: > >> > You want to look at A and see whether its limit was responsible for -> >> > reclaim scans in any children. IMO, that is asking the question -> >> > backwards. Instead, there is a cgroup under reclaim and one wants to -> >> > find out the cause for that. Not the other way round. +> >> > reclaim scans in any children. IMO, that is asking the question +> >> > backwards. Instead, there is a cgroup under reclaim and one wants to +> >> > find out the cause for that. Not the other way round. > >> > > >> > In my original proposal I suggested differentiating reclaim caused by > >> > internal pressure (due to own limit) and reclaim caused by > >> > external/hierarchical pressure (due to limits from parents). > >> > > >> > If you want to find out why C is under reclaim, look at its reclaim -> >> > statistics. If the _limit numbers are high, C's limit is the problem. +> >> > statistics. If the _limit numbers are high, C's limit is the problem. > >> > If the _hierarchical numbers are high, the problem is B, A, or > >> > physical memory, so you check B for _limit and _hierarchical as well, > >> > then move on to A. @@ -21,8 +21,8 @@ On Thu, Sep 01, 2011 at 12:04:24AM -0700, Ying Han wrote: > >> > scan (victim) to the reclaim code, but also the memcg /causing/ the > >> > reclaim (root_mem): > >> > -> >> > root_mem == victim -> account to victim as _limit -> >> > root_mem != victim -> account to victim as _hierarchical +> >> > root_mem == victim -> account to victim as _limit +> >> > root_mem != victim -> account to victim as _hierarchical > >> > > >> > This would make things much simpler and more natural, both the code > >> > and the way of tracking down a problem, IMO. @@ -40,7 +40,7 @@ On Thu, Sep 01, 2011 at 12:04:24AM -0700, Ying Han wrote: > >> per-memcg reclaim. > >> "_under_hiearchy" is set if memcg is not the one triggering pressure. > > -> > I don't get this distinction between _system and _limit. How is it +> > I don't get this distinction between _system and _limit. How is it > > orthogonal to _limit vs. _hierarchy, i.e. internal vs. external? > > Something like : @@ -103,3 +103,10 @@ limit. What makes the physical memory limit special that requires the resulting reclaims to be designated over reclaims due to other hierarchical limits? + +-- +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 57c199d..5f162ad 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -26,16 +26,16 @@ "> > On Wed, Aug 31, 2011 at 11:05:51PM -0700, Ying Han wrote:\n" "> >> On Tue, Aug 30, 2011 at 1:42 AM, Johannes Weiner <jweiner@redhat.com> wrote:\n" "> >> > You want to look at A and see whether its limit was responsible for\n" - "> >> > reclaim scans in any children. \302\240IMO, that is asking the question\n" - "> >> > backwards. \302\240Instead, there is a cgroup under reclaim and one wants to\n" - "> >> > find out the cause for that. \302\240Not the other way round.\n" + "> >> > reclaim scans in any children. IMO, that is asking the question\n" + "> >> > backwards. Instead, there is a cgroup under reclaim and one wants to\n" + "> >> > find out the cause for that. Not the other way round.\n" "> >> >\n" "> >> > In my original proposal I suggested differentiating reclaim caused by\n" "> >> > internal pressure (due to own limit) and reclaim caused by\n" "> >> > external/hierarchical pressure (due to limits from parents).\n" "> >> >\n" "> >> > If you want to find out why C is under reclaim, look at its reclaim\n" - "> >> > statistics. \302\240If the _limit numbers are high, C's limit is the problem.\n" + "> >> > statistics. If the _limit numbers are high, C's limit is the problem.\n" "> >> > If the _hierarchical numbers are high, the problem is B, A, or\n" "> >> > physical memory, so you check B for _limit and _hierarchical as well,\n" "> >> > then move on to A.\n" @@ -44,8 +44,8 @@ "> >> > scan (victim) to the reclaim code, but also the memcg /causing/ the\n" "> >> > reclaim (root_mem):\n" "> >> >\n" - "> >> > \302\240 \302\240 \302\240 \302\240root_mem == victim -> account to victim as _limit\n" - "> >> > \302\240 \302\240 \302\240 \302\240root_mem != victim -> account to victim as _hierarchical\n" + "> >> > root_mem == victim -> account to victim as _limit\n" + "> >> > root_mem != victim -> account to victim as _hierarchical\n" "> >> >\n" "> >> > This would make things much simpler and more natural, both the code\n" "> >> > and the way of tracking down a problem, IMO.\n" @@ -63,7 +63,7 @@ "> >> per-memcg reclaim.\n" "> >> \"_under_hiearchy\" is set if memcg is not the one triggering pressure.\n" "> >\n" - "> > I don't get this distinction between _system and _limit. \302\240How is it\n" + "> > I don't get this distinction between _system and _limit. How is it\n" "> > orthogonal to _limit vs. _hierarchy, i.e. internal vs. external?\n" "> \n" "> Something like :\n" @@ -125,6 +125,13 @@ "\n" "What makes the physical memory limit special that requires the\n" "resulting reclaims to be designated over reclaims due to other\n" - hierarchical limits? + "hierarchical limits?\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>" -94eca36d028a983d26d21dc398dcf25719fef4c8b766158f01d041ffdeff9c15 +4c7fff129577a0d192d8b12e02443f18764ec317b0929caf77c8ff36b0cf0710
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.