diff for duplicates of <20110901064034.GC22561@redhat.com> diff --git a/a/1.txt b/N1/1.txt index fb9c7e4..755bdc5 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,16 +1,16 @@ 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. @@ -19,8 +19,8 @@ On Wed, Aug 31, 2011 at 11:05:51PM -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. @@ -49,3 +49,10 @@ and scanned_pages_by_system_under_hierarchy? The reason for scanned_pages_by_system would be, per your definition, neither due to the limit (_by_system -> global reclaim) nor not due to the limit (!_under_hierarchy -> memcg is the one triggering pressure) + +-- +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 3088085..768b84f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -24,16 +24,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" @@ -42,8 +42,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" @@ -71,6 +71,13 @@ "and scanned_pages_by_system_under_hierarchy? The reason for\n" "scanned_pages_by_system would be, per your definition, neither due to\n" "the limit (_by_system -> global reclaim) nor not due to the limit\n" - (!_under_hierarchy -> memcg is the one triggering pressure) + "(!_under_hierarchy -> memcg is the one triggering pressure)\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>" -ad62f94ace3c6e565a960036a5de227977a729e64c8c73fc1f572b10fd852a6d +31c4cbfd6ac55dfc0d01e253e1a73b9c18114d6e89c5b0592860e5a7a6b40e4d
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.