diff for duplicates of <20110609212644.GL29913@redhat.com> diff --git a/a/1.txt b/N1/1.txt index f68fc01..6e2d9f7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -87,10 +87,3 @@ No this is not related to throttling of async writes. Thanks Vivek - --- -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 bfd07a1..ec05d29 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -116,13 +116,6 @@ "No this is not related to throttling of async writes.\n" "\n" "Thanks\n" - "Vivek\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>" + Vivek -0940a21dd6291afa38baebd0559a545031e10f6e94355259b6e34a192663c692 +fe43efcdb7bca2f495d2ab8ae28caa418a4e991cfccba52d65692dc67a98185a
diff --git a/a/1.txt b/N2/1.txt index f68fc01..7154638 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -14,40 +14,40 @@ On Thu, Jun 09, 2011 at 10:55:40AM -0700, Greg Thelen wrote: > >> > Thanks, > >> > -Kame > >> -> >> Not quite. The proposed patches do not set the "1" bit (css_id of -> >> root is 1). mem_cgroup_balance_dirty_pages() (from patch 10/12) +> >> Not quite. The proposed patches do not set the "1" bit (css_id of +> >> root is 1). mem_cgroup_balance_dirty_pages() (from patch 10/12) > >> introduces the following balancing loop: -> >> + /* balance entire ancestry of current's mem. */ -> >> + for (; mem_cgroup_has_dirty_limit(mem); mem = +> >> + /* balance entire ancestry of current's mem. */ +> >> + for (; mem_cgroup_has_dirty_limit(mem); mem = > >> parent_mem_cgroup(mem)) { > >> > >> The loop terminates when mem_cgroup_has_dirty_limit() is called for -> >> the root cgroup. The bitmap is set in the body of the loop. So the -> >> root cgroup's bit (bit 1) will never be set in the bitmap. However, I -> >> think the effect is the same. The proposed changes in this patch +> >> the root cgroup. The bitmap is set in the body of the loop. So the +> >> root cgroup's bit (bit 1) will never be set in the bitmap. However, I +> >> think the effect is the same. The proposed changes in this patch > >> (11/12) have background writeback first checking if the system is over -> >> limit and if yes, then b_dirty inodes from any cgroup written. This +> >> limit and if yes, then b_dirty inodes from any cgroup written. This > >> means that a small system background limit with an over-{fg or > >> bg}-limit cgroup could cause other cgroups that are not over their -> >> limit to have their inodes written back. In an system-over-limit +> >> limit to have their inodes written back. In an system-over-limit > >> situation normal system-wide bdi writeback is used (writing inodes in -> >> b_dirty order). For those who want isolation, a simple rule to avoid +> >> b_dirty order). For those who want isolation, a simple rule to avoid > >> this is to ensure that that sum of all cgroup background_limits is > >> less than the system background limit. > > > > Ok, we seem to be mixing multiple things. > > > > - First of all, i thought running apps in root group is very valid -> > use case. Generally by default we run everything in root group and -> > once somebody notices that an application or group of application -> > is memory hog, that can be moved out in a cgroup of its own with -> > upper limits. +> > use case. Generally by default we run everything in root group and +> > once somebody notices that an application or group of application +> > is memory hog, that can be moved out in a cgroup of its own with +> > upper limits. > > > > - Secondly, root starvation issue is not present as long as we fall -> > back to normal way of writting inodes once we have crossed dirty -> > limit. But you had suggested that we move cgroup based writeout -> > above so that we always use same scheme for writeout and that -> > potentially will have root starvation issue. +> > back to normal way of writting inodes once we have crossed dirty +> > limit. But you had suggested that we move cgroup based writeout +> > above so that we always use same scheme for writeout and that +> > potentially will have root starvation issue. > > To reduce the risk of breaking system writeback (by potentially > starting root inodes), my preference is to to retain this patch's @@ -55,7 +55,7 @@ On Thu, Jun 09, 2011 at 10:55:40AM -0700, Greg Thelen wrote: > if under system limits write per-cgroup). > > > - If we don't move it up, then atleast it will not work for CFQ IO -> > controller. +> > controller. > > As originally proposed, over_bground_thresh() would check system > background limit, and if over limit then write b_dirty, until under diff --git a/a/content_digest b/N2/content_digest index bfd07a1..a6e5ac1 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -44,40 +44,40 @@ "> >> > Thanks,\n" "> >> > -Kame\n" "> >>\n" - "> >> Not quite. \302\240The proposed patches do not set the \"1\" bit (css_id of\n" - "> >> root is 1). \302\240mem_cgroup_balance_dirty_pages() (from patch 10/12)\n" + "> >> Not quite. The proposed patches do not set the \"1\" bit (css_id of\n" + "> >> root is 1). mem_cgroup_balance_dirty_pages() (from patch 10/12)\n" "> >> introduces the following balancing loop:\n" - "> >> + \302\240 \302\240 \302\240 /* balance entire ancestry of current's mem. */\n" - "> >> + \302\240 \302\240 \302\240 for (; mem_cgroup_has_dirty_limit(mem); mem =\n" + "> >> + /* balance entire ancestry of current's mem. */\n" + "> >> + for (; mem_cgroup_has_dirty_limit(mem); mem =\n" "> >> parent_mem_cgroup(mem)) {\n" "> >>\n" "> >> The loop terminates when mem_cgroup_has_dirty_limit() is called for\n" - "> >> the root cgroup. \302\240The bitmap is set in the body of the loop. \302\240So the\n" - "> >> root cgroup's bit (bit 1) will never be set in the bitmap. \302\240However, I\n" - "> >> think the effect is the same. \302\240The proposed changes in this patch\n" + "> >> the root cgroup. The bitmap is set in the body of the loop. So the\n" + "> >> root cgroup's bit (bit 1) will never be set in the bitmap. However, I\n" + "> >> think the effect is the same. The proposed changes in this patch\n" "> >> (11/12) have background writeback first checking if the system is over\n" - "> >> limit and if yes, then b_dirty inodes from any cgroup written. \302\240This\n" + "> >> limit and if yes, then b_dirty inodes from any cgroup written. This\n" "> >> means that a small system background limit with an over-{fg or\n" "> >> bg}-limit cgroup could cause other cgroups that are not over their\n" - "> >> limit to have their inodes written back. \302\240In an system-over-limit\n" + "> >> limit to have their inodes written back. In an system-over-limit\n" "> >> situation normal system-wide bdi writeback is used (writing inodes in\n" - "> >> b_dirty order). \302\240For those who want isolation, a simple rule to avoid\n" + "> >> b_dirty order). For those who want isolation, a simple rule to avoid\n" "> >> this is to ensure that that sum of all cgroup background_limits is\n" "> >> less than the system background limit.\n" "> >\n" "> > Ok, we seem to be mixing multiple things.\n" "> >\n" "> > - First of all, i thought running apps in root group is very valid\n" - "> > \302\240use case. Generally by default we run everything in root group and\n" - "> > \302\240once somebody notices that an application or group of application\n" - "> > \302\240is memory hog, that can be moved out in a cgroup of its own with\n" - "> > \302\240upper limits.\n" + "> > use case. Generally by default we run everything in root group and\n" + "> > once somebody notices that an application or group of application\n" + "> > is memory hog, that can be moved out in a cgroup of its own with\n" + "> > upper limits.\n" "> >\n" "> > - Secondly, root starvation issue is not present as long as we fall\n" - "> > \302\240back to normal way of writting inodes once we have crossed dirty\n" - "> > \302\240limit. But you had suggested that we move cgroup based writeout\n" - "> > \302\240above so that we always use same scheme for writeout and that\n" - "> > \302\240potentially will have root starvation issue.\n" + "> > back to normal way of writting inodes once we have crossed dirty\n" + "> > limit. But you had suggested that we move cgroup based writeout\n" + "> > above so that we always use same scheme for writeout and that\n" + "> > potentially will have root starvation issue.\n" "> \n" "> To reduce the risk of breaking system writeback (by potentially\n" "> starting root inodes), my preference is to to retain this patch's\n" @@ -85,7 +85,7 @@ "> if under system limits write per-cgroup).\n" "> \n" "> > - If we don't move it up, then atleast it will not work for CFQ IO\n" - "> > \302\240controller.\n" + "> > controller.\n" "> \n" "> As originally proposed, over_bground_thresh() would check system\n" "> background limit, and if over limit then write b_dirty, until under\n" @@ -125,4 +125,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>" -0940a21dd6291afa38baebd0559a545031e10f6e94355259b6e34a192663c692 +cd314c1855932ba5e070ca5675e0ab350ba0d0ab58ab72483bac3e7ed1963c26
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.