All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20110517055204.GB24069@localhost>

diff --git a/a/1.txt b/N1/1.txt
index 1897cf2..301eda7 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -9,7 +9,7 @@ On Mon, May 16, 2011 at 07:40:42AM +0900, Minchan Kim wrote:
 > >> >> If it's a culprit, the patch should solve the problem.
 > >> >
 > >> > It would be probably better to not do the allocations at all under
-> >> > memory pressure.  Even if the RA allocation doesn't go into reclaim
+> >> > memory pressure. A Even if the RA allocation doesn't go into reclaim
 > >>
 > >> Fair enough.
 > >> I think we can do it easily now.
@@ -29,7 +29,7 @@ I see.
 > >
 > > The sequential readahead memory consumption can be estimated by
 > >
-> >                2 * (number of concurrent read streams) * (readahead window size)
+> > A  A  A  A  A  A  A  A 2 * (number of concurrent read streams) * (readahead window size)
 > >
 > > And you can double that when there are two level of readaheads.
 > >
@@ -49,8 +49,8 @@ adaptively to the available page cache memory :)
 
 > >
 > > - shrink readahead window on readahead thrashing
-> >  (current readahead heuristic can somehow do this, and I have patches
-> >  to further improve it)
+> > A (current readahead heuristic can somehow do this, and I have patches
+> > A to further improve it)
 > 
 > Good to hear. :)
 > I don't want RA steals high order page in memory pressure.
@@ -63,3 +63,10 @@ some more general order-0 steal order-N problem..
 
 Thanks,
 Fengguang
+
+--
+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 0810350..7db6e48 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -29,7 +29,7 @@
  "> >> >> If it's a culprit, the patch should solve the problem.\n"
  "> >> >\n"
  "> >> > It would be probably better to not do the allocations at all under\n"
- "> >> > memory pressure. \302\240Even if the RA allocation doesn't go into reclaim\n"
+ "> >> > memory pressure. A Even if the RA allocation doesn't go into reclaim\n"
  "> >>\n"
  "> >> Fair enough.\n"
  "> >> I think we can do it easily now.\n"
@@ -49,7 +49,7 @@
  "> >\n"
  "> > The sequential readahead memory consumption can be estimated by\n"
  "> >\n"
- "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\2402 * (number of concurrent read streams) * (readahead window size)\n"
+ "> > A  A  A  A  A  A  A  A 2 * (number of concurrent read streams) * (readahead window size)\n"
  "> >\n"
  "> > And you can double that when there are two level of readaheads.\n"
  "> >\n"
@@ -69,8 +69,8 @@
  "\n"
  "> >\n"
  "> > - shrink readahead window on readahead thrashing\n"
- "> > \302\240(current readahead heuristic can somehow do this, and I have patches\n"
- "> > \302\240to further improve it)\n"
+ "> > A (current readahead heuristic can somehow do this, and I have patches\n"
+ "> > A to further improve it)\n"
  "> \n"
  "> Good to hear. :)\n"
  "> I don't want RA steals high order page in memory pressure.\n"
@@ -82,6 +82,13 @@
  "> My patch and shrinking RA window helps this case.\n"
  "\n"
  "Thanks,\n"
- Fengguang
+ "Fengguang\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>"
 
-3e2559b174e40694391df1087dd37d07d599c2ad2262af94c8d0efc299073de2
+6b03e97747dc7c2853b781bf8f8297f294f49f3a4e67700256768616ab648f43

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.