diff for duplicates of <20110317225657.GI10482@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 8fdaa8e..806f018 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,24 +5,24 @@ On Thu, Mar 17, 2011 at 11:55:34AM -0700, Curt Wohlgemuth wrote: > >> The design of IO-less foreground throttling of writeback in the context of > >> memory cgroups is being discussed in the memcg patch threads (e.g., > >> "[PATCH v6 0/9] memcg: per cgroup dirty page accounting"), but I've got -> >> another concern as well. And that's how restricting per-BDI writeback to a +> >> another concern as well. And that's how restricting per-BDI writeback to a > >> single task will affect proposed changes for tracking and accounting of > >> buffered writes to the IO scheduler ("[RFC] [PATCH 0/6] Provide cgroup > >> isolation for buffered writes", https://lkml.org/lkml/2011/3/8/332 ). > >> > >> It seems totally reasonable that reducing competition for write requests to > >> a BDI -- by using the flusher thread to "handle" foreground writeout -- -> >> would increase throughput to that device. At Google, we experiemented with +> >> would increase throughput to that device. At Google, we experiemented with > >> this in a hacked-up fashion several months ago (FG task would enqueue a work > >> item and sleep for some period of time, wake up and see if it was below the > >> dirty limit), and found that we were indeed getting better throughput. > >> > >> But if one of one's goals is to provide some sort of disk isolation based on > >> cgroup parameters, than having at most one stream of write requests -> >> effectively neuters the IO scheduler. We saw that in practice, which led to +> >> effectively neuters the IO scheduler. We saw that in practice, which led to > >> abandoning our attempt at "IO-less throttling." > -> > Let me check if I understand: The problem you have with one flusher +> > Let me check if I understand: The problem you have with one flusher > > thread is that when written pages all belong to a single memcg, there is > > nothing IO scheduler can prioritize, right? > diff --git a/a/content_digest b/N1/content_digest index d4a1e49..9271132 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -25,24 +25,24 @@ "> >> The design of IO-less foreground throttling of writeback in the context of\n" "> >> memory cgroups is being discussed in the memcg patch threads (e.g.,\n" "> >> \"[PATCH v6 0/9] memcg: per cgroup dirty page accounting\"), but I've got\n" - "> >> another concern as well. \302\240And that's how restricting per-BDI writeback to a\n" + "> >> another concern as well. And that's how restricting per-BDI writeback to a\n" "> >> single task will affect proposed changes for tracking and accounting of\n" "> >> buffered writes to the IO scheduler (\"[RFC] [PATCH 0/6] Provide cgroup\n" "> >> isolation for buffered writes\", https://lkml.org/lkml/2011/3/8/332 ).\n" "> >>\n" "> >> It seems totally reasonable that reducing competition for write requests to\n" "> >> a BDI -- by using the flusher thread to \"handle\" foreground writeout --\n" - "> >> would increase throughput to that device. \302\240At Google, we experiemented with\n" + "> >> would increase throughput to that device. At Google, we experiemented with\n" "> >> this in a hacked-up fashion several months ago (FG task would enqueue a work\n" "> >> item and sleep for some period of time, wake up and see if it was below the\n" "> >> dirty limit), and found that we were indeed getting better throughput.\n" "> >>\n" "> >> But if one of one's goals is to provide some sort of disk isolation based on\n" "> >> cgroup parameters, than having at most one stream of write requests\n" - "> >> effectively neuters the IO scheduler. \302\240We saw that in practice, which led to\n" + "> >> effectively neuters the IO scheduler. We saw that in practice, which led to\n" "> >> abandoning our attempt at \"IO-less throttling.\"\n" "> \n" - "> > \302\240Let me check if I understand: The problem you have with one flusher\n" + "> > Let me check if I understand: The problem you have with one flusher\n" "> > thread is that when written pages all belong to a single memcg, there is\n" "> > nothing IO scheduler can prioritize, right?\n" "> \n" @@ -110,4 +110,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>" -d4569ea098e123ca6a6938e2febed9d1549f212cdc3eef6891e91c53e858e644 +382a78ddeca75eb88289213f3202ad587c0c83ba115996aa4378827b438da59f
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.