All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20120622192919.GL4642@google.com>

diff --git a/a/1.txt b/N1/1.txt
index 1259919..47ebfb3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,11 +1,11 @@
 Hello, Yinghai.
 
 On Fri, Jun 22, 2012 at 12:23:24PM -0700, Yinghai Lu wrote:
-> > Thanks for checking it.  I was worried because of the re-reservation
+> > Thanks for checking it.  I was worried because of the re-reservation
 > > of reserved.regions after giving memory to the page allocator -
-> > ie. memblock_reserve_reserved_regions() call.  If memblock is done at
-> > that point, there's no reason to have that call at all.  It could be
-> > that that's just dead code.  If so, why aren't we freeing
+> > ie. memblock_reserve_reserved_regions() call.  If memblock is done at
+> > that point, there's no reason to have that call at all.  It could be
+> > that that's just dead code.  If so, why aren't we freeing
 > > memory.regions?
 > 
 > During converting bootmem to use early_res stage, I still kept the
@@ -25,7 +25,7 @@ Thanks for the explanation.
 
 > > Also, shouldn't we be clearing
 > > memblock.cnt/max/total_size/regions so that we know for sure that it's
-> > never used again?  What am I missing?
+> > never used again?  What am I missing?
 > 
 > 64bit mem_init(), after absent_page_in_range(), will not need memblock anymore.
 >   --- absent_page_in_range will refer for_each_mem_pfn_range.
@@ -42,9 +42,3 @@ Thanks.
 
 -- 
 tejun
-
---
-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/ .
-Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N1/content_digest
index ec46f75..e9daa96 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -24,11 +24,11 @@
  "Hello, Yinghai.\n"
  "\n"
  "On Fri, Jun 22, 2012 at 12:23:24PM -0700, Yinghai Lu wrote:\n"
- "> > Thanks for checking it.  I was worried because of the re-reservation\n"
+ "> > Thanks for checking it. \302\240I was worried because of the re-reservation\n"
  "> > of reserved.regions after giving memory to the page allocator -\n"
- "> > ie. memblock_reserve_reserved_regions() call.  If memblock is done at\n"
- "> > that point, there's no reason to have that call at all.  It could be\n"
- "> > that that's just dead code.  If so, why aren't we freeing\n"
+ "> > ie. memblock_reserve_reserved_regions() call. \302\240If memblock is done at\n"
+ "> > that point, there's no reason to have that call at all. \302\240It could be\n"
+ "> > that that's just dead code. \302\240If so, why aren't we freeing\n"
  "> > memory.regions?\n"
  "> \n"
  "> During converting bootmem to use early_res stage, I still kept the\n"
@@ -48,7 +48,7 @@
  "\n"
  "> > Also, shouldn't we be clearing\n"
  "> > memblock.cnt/max/total_size/regions so that we know for sure that it's\n"
- "> > never used again?  What am I missing?\n"
+ "> > never used again? \302\240What am I missing?\n"
  "> \n"
  "> 64bit mem_init(), after absent_page_in_range(), will not need memblock anymore.\n"
  ">   --- absent_page_in_range will refer for_each_mem_pfn_range.\n"
@@ -64,12 +64,6 @@
  "Thanks.\n"
  "\n"
  "-- \n"
- "tejun\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"
- "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
+ tejun
 
-107e4b3ea667e4b73f91e0f8e925434d954688d81842bc4713817e163bcc4fdb
+980cd11ffa370b587bc8190397060c753df16f7ad3ccd842c10f1d6f84642b5a

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.