All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20110602175142.GH28684@cmpxchg.org>

diff --git a/a/1.txt b/N1/1.txt
index 2d6e819..9b35589 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -6,48 +6,48 @@ On Thu, Jun 02, 2011 at 08:51:39AM -0700, Ying Han wrote:
 > >> > 2011/6/1 Johannes Weiner <hannes@cmpxchg.org>:
 > >> >> Hi,
 > >> >>
-> >> >> this is the second version of the memcg naturalization series.  The
+> >> >> this is the second version of the memcg naturalization series.  The
 > >> >> notable changes since the first submission are:
 > >> >>
-> >> >>    o the hierarchy walk is now intermittent and will abort and
-> >> >>      remember the last scanned child after sc->nr_to_reclaim pages
-> >> >>      have been reclaimed during the walk in one zone (Rik)
+> >> >>    o the hierarchy walk is now intermittent and will abort and
+> >> >>      remember the last scanned child after sc->nr_to_reclaim pages
+> >> >>      have been reclaimed during the walk in one zone (Rik)
 > >> >>
-> >> >>    o the global lru lists are never scanned when memcg is enabled
-> >> >>      after #2 'memcg-aware global reclaim', which makes this patch
-> >> >>      self-sufficient and complete without requiring the per-memcg lru
-> >> >>      lists to be exclusive (Michal)
+> >> >>    o the global lru lists are never scanned when memcg is enabled
+> >> >>      after #2 'memcg-aware global reclaim', which makes this patch
+> >> >>      self-sufficient and complete without requiring the per-memcg lru
+> >> >>      lists to be exclusive (Michal)
 > >> >>
-> >> >>    o renamed sc->memcg and sc->current_memcg to sc->target_mem_cgroup
-> >> >>      and sc->mem_cgroup and fixed their documentation, I hope this is
-> >> >>      better understandable now (Rik)
+> >> >>    o renamed sc->memcg and sc->current_memcg to sc->target_mem_cgroup
+> >> >>      and sc->mem_cgroup and fixed their documentation, I hope this is
+> >> >>      better understandable now (Rik)
 > >> >>
-> >> >>    o the reclaim statistic counters have been renamed.  there is no
-> >> >>      more distinction between 'pgfree' and 'pgsteal', it is now
-> >> >>      'pgreclaim' in both cases; 'kswapd' has been replaced by
-> >> >>      'background'
+> >> >>    o the reclaim statistic counters have been renamed.  there is no
+> >> >>      more distinction between 'pgfree' and 'pgsteal', it is now
+> >> >>      'pgreclaim' in both cases; 'kswapd' has been replaced by
+> >> >>      'background'
 > >> >>
-> >> >>    o fixed a nasty crash in the hierarchical soft limit check that
-> >> >>      happened during global reclaim in memcgs that are hierarchical
-> >> >>      but have no hierarchical parents themselves
+> >> >>    o fixed a nasty crash in the hierarchical soft limit check that
+> >> >>      happened during global reclaim in memcgs that are hierarchical
+> >> >>      but have no hierarchical parents themselves
 > >> >>
-> >> >>    o properly implemented the memcg-aware unevictable page rescue
-> >> >>      scanner, there were several blatant bugs in there
+> >> >>    o properly implemented the memcg-aware unevictable page rescue
+> >> >>      scanner, there were several blatant bugs in there
 > >> >>
-> >> >>    o documentation on new public interfaces
+> >> >>    o documentation on new public interfaces
 > >> >>
 > >> >> Thanks for your input on the first version.
 > >> >>
 > >> >> I ran microbenchmarks (sparse file catting, essentially) to stress
-> >> >> reclaim and LRU operations.  There is no measurable overhead for
+> >> >> reclaim and LRU operations.  There is no measurable overhead for
 > >> >> !CONFIG_MEMCG, memcg disabled during boot, memcg enabled but no
 > >> >> configured groups, and hard limit reclaim.
 > >> >>
 > >> >> I also ran single-threaded kernbenchs in four unlimited memcgs in
 > >> >> parallel, contained in a hard-limited hierarchical parent that put
-> >> >> constant pressure on the workload.  There is no measurable difference
+> >> >> constant pressure on the workload.  There is no measurable difference
 > >> >> in runtime, the pgpgin/pgpgout counters, and fairness among memcgs in
-> >> >> this test compared to an unpatched kernel.  Needs more evaluation,
+> >> >> this test compared to an unpatched kernel.  Needs more evaluation,
 > >> >> especially with a higher number of memcgs.
 > >> >>
 > >> >> The soft limit changes are also proven to work in so far that it is
@@ -62,8 +62,8 @@ On Thu, Jun 02, 2011 at 08:51:39AM -0700, Ying Han wrote:
 > >> > Hmm, I welcome and will review this patches but.....some points I want to say.
 > >> >
 > >> > 1. No more conflict with Ying's work ?
-> >> >    Could you explain what she has and what you don't in this v2 ?
-> >> >    If Ying's one has something good to be merged to your set, please
+> >> >    Could you explain what she has and what you don't in this v2 ?
+> >> >    If Ying's one has something good to be merged to your set, please
 > >> > include it.
 > >>
 > >> My patch I sent out last time was doing rework of soft_limit reclaim.
@@ -77,13 +77,13 @@ On Thu, Jun 02, 2011 at 08:51:39AM -0700, Ying Han wrote:
 > > Thanks!!
 > >
 > >> > 4. This work can be splitted into some small works.
-> >> >     a) fix for current code and clean ups
+> >> >     a) fix for current code and clean ups
 > >>
-> >> >     a') statistics
+> >> >     a') statistics
 > >>
-> >> >     b) soft limit rework
+> >> >     b) soft limit rework
 > >>
-> >> >     c) change global reclaim
+> >> >     c) change global reclaim
 > >>
 > >> My last patchset starts with a patch reverting the RB-tree
 > >> implementation of the soft_limit
@@ -98,8 +98,8 @@ On Thu, Jun 02, 2011 at 08:51:39AM -0700, Ying Han wrote:
 > >>
 > >> Sorry If that is how it is done here. I will read through the patchset.
 > >
-> > It's not.  The way I implemented soft limits depends on global reclaim
-> > performing hierarchical reclaim.  I don't see how I can reverse the
+> > It's not.  The way I implemented soft limits depends on global reclaim
+> > performing hierarchical reclaim.  I don't see how I can reverse the
 > > order with this dependency.
 > 
 > That is something I don't quite get yet, and maybe need a closer look
@@ -142,3 +142,10 @@ the long run.
 I agree with Andrew: we either need to prove it's the way to go, or
 prove that we never want to do it like this.  Before we start adding
 statistics that commit us to one way or the other.
+
+--
+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 0ef8860..d4840db 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -31,48 +31,48 @@
  "> >> > 2011/6/1 Johannes Weiner <hannes@cmpxchg.org>:\n"
  "> >> >> Hi,\n"
  "> >> >>\n"
- "> >> >> this is the second version of the memcg naturalization series. \302\240The\n"
+ "> >> >> this is the second version of the memcg naturalization series.  The\n"
  "> >> >> notable changes since the first submission are:\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o the hierarchy walk is now intermittent and will abort and\n"
- "> >> >> \302\240 \302\240 \302\240remember the last scanned child after sc->nr_to_reclaim pages\n"
- "> >> >> \302\240 \302\240 \302\240have been reclaimed during the walk in one zone (Rik)\n"
+ "> >> >>    o the hierarchy walk is now intermittent and will abort and\n"
+ "> >> >>      remember the last scanned child after sc->nr_to_reclaim pages\n"
+ "> >> >>      have been reclaimed during the walk in one zone (Rik)\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o the global lru lists are never scanned when memcg is enabled\n"
- "> >> >> \302\240 \302\240 \302\240after #2 'memcg-aware global reclaim', which makes this patch\n"
- "> >> >> \302\240 \302\240 \302\240self-sufficient and complete without requiring the per-memcg lru\n"
- "> >> >> \302\240 \302\240 \302\240lists to be exclusive (Michal)\n"
+ "> >> >>    o the global lru lists are never scanned when memcg is enabled\n"
+ "> >> >>      after #2 'memcg-aware global reclaim', which makes this patch\n"
+ "> >> >>      self-sufficient and complete without requiring the per-memcg lru\n"
+ "> >> >>      lists to be exclusive (Michal)\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o renamed sc->memcg and sc->current_memcg to sc->target_mem_cgroup\n"
- "> >> >> \302\240 \302\240 \302\240and sc->mem_cgroup and fixed their documentation, I hope this is\n"
- "> >> >> \302\240 \302\240 \302\240better understandable now (Rik)\n"
+ "> >> >>    o renamed sc->memcg and sc->current_memcg to sc->target_mem_cgroup\n"
+ "> >> >>      and sc->mem_cgroup and fixed their documentation, I hope this is\n"
+ "> >> >>      better understandable now (Rik)\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o the reclaim statistic counters have been renamed. \302\240there is no\n"
- "> >> >> \302\240 \302\240 \302\240more distinction between 'pgfree' and 'pgsteal', it is now\n"
- "> >> >> \302\240 \302\240 \302\240'pgreclaim' in both cases; 'kswapd' has been replaced by\n"
- "> >> >> \302\240 \302\240 \302\240'background'\n"
+ "> >> >>    o the reclaim statistic counters have been renamed.  there is no\n"
+ "> >> >>      more distinction between 'pgfree' and 'pgsteal', it is now\n"
+ "> >> >>      'pgreclaim' in both cases; 'kswapd' has been replaced by\n"
+ "> >> >>      'background'\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o fixed a nasty crash in the hierarchical soft limit check that\n"
- "> >> >> \302\240 \302\240 \302\240happened during global reclaim in memcgs that are hierarchical\n"
- "> >> >> \302\240 \302\240 \302\240but have no hierarchical parents themselves\n"
+ "> >> >>    o fixed a nasty crash in the hierarchical soft limit check that\n"
+ "> >> >>      happened during global reclaim in memcgs that are hierarchical\n"
+ "> >> >>      but have no hierarchical parents themselves\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o properly implemented the memcg-aware unevictable page rescue\n"
- "> >> >> \302\240 \302\240 \302\240scanner, there were several blatant bugs in there\n"
+ "> >> >>    o properly implemented the memcg-aware unevictable page rescue\n"
+ "> >> >>      scanner, there were several blatant bugs in there\n"
  "> >> >>\n"
- "> >> >> \302\240 \302\240o documentation on new public interfaces\n"
+ "> >> >>    o documentation on new public interfaces\n"
  "> >> >>\n"
  "> >> >> Thanks for your input on the first version.\n"
  "> >> >>\n"
  "> >> >> I ran microbenchmarks (sparse file catting, essentially) to stress\n"
- "> >> >> reclaim and LRU operations. \302\240There is no measurable overhead for\n"
+ "> >> >> reclaim and LRU operations.  There is no measurable overhead for\n"
  "> >> >> !CONFIG_MEMCG, memcg disabled during boot, memcg enabled but no\n"
  "> >> >> configured groups, and hard limit reclaim.\n"
  "> >> >>\n"
  "> >> >> I also ran single-threaded kernbenchs in four unlimited memcgs in\n"
  "> >> >> parallel, contained in a hard-limited hierarchical parent that put\n"
- "> >> >> constant pressure on the workload. \302\240There is no measurable difference\n"
+ "> >> >> constant pressure on the workload.  There is no measurable difference\n"
  "> >> >> in runtime, the pgpgin/pgpgout counters, and fairness among memcgs in\n"
- "> >> >> this test compared to an unpatched kernel. \302\240Needs more evaluation,\n"
+ "> >> >> this test compared to an unpatched kernel.  Needs more evaluation,\n"
  "> >> >> especially with a higher number of memcgs.\n"
  "> >> >>\n"
  "> >> >> The soft limit changes are also proven to work in so far that it is\n"
@@ -87,8 +87,8 @@
  "> >> > Hmm, I welcome and will review this patches but.....some points I want to say.\n"
  "> >> >\n"
  "> >> > 1. No more conflict with Ying's work ?\n"
- "> >> > \302\240 \302\240Could you explain what she has and what you don't in this v2 ?\n"
- "> >> > \302\240 \302\240If Ying's one has something good to be merged to your set, please\n"
+ "> >> >    Could you explain what she has and what you don't in this v2 ?\n"
+ "> >> >    If Ying's one has something good to be merged to your set, please\n"
  "> >> > include it.\n"
  "> >>\n"
  "> >> My patch I sent out last time was doing rework of soft_limit reclaim.\n"
@@ -102,13 +102,13 @@
  "> > Thanks!!\n"
  "> >\n"
  "> >> > 4. This work can be splitted into some small works.\n"
- "> >> > \302\240 \302\240 a) fix for current code and clean ups\n"
+ "> >> >     a) fix for current code and clean ups\n"
  "> >>\n"
- "> >> > \302\240 \302\240 a') statistics\n"
+ "> >> >     a') statistics\n"
  "> >>\n"
- "> >> > \302\240 \302\240 b) soft limit rework\n"
+ "> >> >     b) soft limit rework\n"
  "> >>\n"
- "> >> > \302\240 \302\240 c) change global reclaim\n"
+ "> >> >     c) change global reclaim\n"
  "> >>\n"
  "> >> My last patchset starts with a patch reverting the RB-tree\n"
  "> >> implementation of the soft_limit\n"
@@ -123,8 +123,8 @@
  "> >>\n"
  "> >> Sorry If that is how it is done here. I will read through the patchset.\n"
  "> >\n"
- "> > It's not. \302\240The way I implemented soft limits depends on global reclaim\n"
- "> > performing hierarchical reclaim. \302\240I don't see how I can reverse the\n"
+ "> > It's not.  The way I implemented soft limits depends on global reclaim\n"
+ "> > performing hierarchical reclaim.  I don't see how I can reverse the\n"
  "> > order with this dependency.\n"
  "> \n"
  "> That is something I don't quite get yet, and maybe need a closer look\n"
@@ -166,6 +166,13 @@
  "\n"
  "I agree with Andrew: we either need to prove it's the way to go, or\n"
  "prove that we never want to do it like this.  Before we start adding\n"
- statistics that commit us to one way or the other.
+ "statistics that commit us to one way or the other.\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>"
 
-af9161262df2b14e43c08dd578944cbcfc3393f148c3cd93e41b7748a7f7e306
+0d51547c13b81063a8738aa675d9b635369f2400b9df904fa9d864afbba78ee0

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.