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

diff --git a/a/1.txt b/N1/1.txt
index f67b599..5fd11e2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -138,7 +138,3 @@ writeback work and have the flusher go through memcg->mappings,
 selecting those that match the bdi.
 
 Am I missing something?  I feel like I missed your point.
---
-To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 1bb9229..21b5117 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -167,10 +167,6 @@
  "writeback work and have the flusher go through memcg->mappings,\n"
  "selecting those that match the bdi.\n"
  "\n"
- "Am I missing something?  I feel like I missed your point.\n"
- "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-fsdevel\" in\n"
- "the body of a message to majordomo@vger.kernel.org\n"
- More majordomo info at  http://vger.kernel.org/majordomo-info.html
+ Am I missing something?  I feel like I missed your point.
 
-51f0f24707a87f095b3c142bffd96b87f51f86de8479fd7c48d46569a002b11f
+3806ac1af6668c9787dba104efa1c5ca440555ea9c8933f7478ac889311cfb6a

diff --git a/a/1.txt b/N2/1.txt
index f67b599..a4cf747 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -7,18 +7,18 @@ On Wed, Mar 16, 2011 at 10:59:59AM -0400, Vivek Goyal wrote:
 > > > > >
 > > > > > [..]
 > > > > >> > We could just crawl the memcg's page LRU and bring things under control
-> > > > >> > that way, couldn't we?  That would fix it.  What were the reasons for
+> > > > >> > that way, couldn't we?  That would fix it.  What were the reasons for
 > > > > >> > not doing this?
 > > > > >>
-> > > > >> My rational for pursuing bdi writeback was I/O locality.  I have heard that
-> > > > >> per-page I/O has bad locality.  Per inode bdi-style writeback should have better
+> > > > >> My rational for pursuing bdi writeback was I/O locality.  I have heard that
+> > > > >> per-page I/O has bad locality.  Per inode bdi-style writeback should have better
 > > > > >> locality.
 > > > > >>
 > > > > >> My hunch is the best solution is a hybrid which uses a) bdi writeback with a
 > > > > >> target memcg filter and b) using the memcg lru as a fallback to identify the bdi
-> > > > >> that needed writeback.  I think the part a) memcg filtering is likely something
+> > > > >> that needed writeback.  I think the part a) memcg filtering is likely something
 > > > > >> like:
-> > > > >>  http://marc.info/?l=linux-kernel&m=129910424431837
+> > > > >>  http://marc.info/?l=linux-kernel&m=129910424431837
 > > > > >>
 > > > > >> The part b) bdi selection should not be too hard assuming that page-to-mapping
 > > > > >> locking is doable.
@@ -138,7 +138,10 @@ writeback work and have the flusher go through memcg->mappings,
 selecting those that match the bdi.
 
 Am I missing something?  I feel like I missed your point.
+
 --
-To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
+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/N2/content_digest
index 1bb9229..41a9908 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -37,18 +37,18 @@
  "> > > > >\n"
  "> > > > > [..]\n"
  "> > > > >> > We could just crawl the memcg's page LRU and bring things under control\n"
- "> > > > >> > that way, couldn't we? \302\240That would fix it. \302\240What were the reasons for\n"
+ "> > > > >> > that way, couldn't we?  That would fix it.  What were the reasons for\n"
  "> > > > >> > not doing this?\n"
  "> > > > >>\n"
- "> > > > >> My rational for pursuing bdi writeback was I/O locality. \302\240I have heard that\n"
- "> > > > >> per-page I/O has bad locality. \302\240Per inode bdi-style writeback should have better\n"
+ "> > > > >> My rational for pursuing bdi writeback was I/O locality.  I have heard that\n"
+ "> > > > >> per-page I/O has bad locality.  Per inode bdi-style writeback should have better\n"
  "> > > > >> locality.\n"
  "> > > > >>\n"
  "> > > > >> My hunch is the best solution is a hybrid which uses a) bdi writeback with a\n"
  "> > > > >> target memcg filter and b) using the memcg lru as a fallback to identify the bdi\n"
- "> > > > >> that needed writeback. \302\240I think the part a) memcg filtering is likely something\n"
+ "> > > > >> that needed writeback.  I think the part a) memcg filtering is likely something\n"
  "> > > > >> like:\n"
- "> > > > >> \302\240http://marc.info/?l=linux-kernel&m=129910424431837\n"
+ "> > > > >>  http://marc.info/?l=linux-kernel&m=129910424431837\n"
  "> > > > >>\n"
  "> > > > >> The part b) bdi selection should not be too hard assuming that page-to-mapping\n"
  "> > > > >> locking is doable.\n"
@@ -168,9 +168,12 @@
  "selecting those that match the bdi.\n"
  "\n"
  "Am I missing something?  I feel like I missed your point.\n"
+ "\n"
  "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-fsdevel\" in\n"
- "the body of a message to majordomo@vger.kernel.org\n"
- More majordomo info at  http://vger.kernel.org/majordomo-info.html
+ "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>"
 
-51f0f24707a87f095b3c142bffd96b87f51f86de8479fd7c48d46569a002b11f
+3f7e3b9e47c9beedd876cec77e7876d8af7b142a74e31198fb48a376a41a52e4

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.