diff for duplicates of <1460064033.20338.74.camel@hpe.com>

diff --git a/a/1.txt b/N1/1.txt
index 19b3372..71feee2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -5,45 +5,47 @@ On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote:
 > > > address without any kernel code.
 > >
 > > An application like NVML can continue to specify a specific address to
-> > mmap().  Most existing applications, however, do not specify an address
-> > to mmap().  With this patch, specifying an address will remain
+> > mmap(). A Most existing applications, however, do not specify an address
+> > to mmap(). A With this patch, specifying an address will remain
 > > optional.
 >
-> The point is that this *can* be done in userspace.  You need to sell us
+> The point is that this *can* be done in userspace.A A You need to sell us
 > on the advantages of doing it in the kernel.
 
-Sure.  As I said, the point is that we do not need to modify existing
+Sure. A As I said, the point is that we do not need to modify existing
 applications for using DAX PMD mappings.
 
 For instance, fio with "ioengine=mmap" performs I/Os with mmap().
 https://github.com/caius/fio/blob/master/engines/mmap.c
 
 With this change, unmodified fio can be used for testing with DAX PMD
-mappings.  There are many examples like this, and I do not think we want to
+mappings. A There are many examples like this, and I do not think we want to
 modify all applications that we want to evaluate/test with.
 
 > > > I think this is the wrong place for it, if we decide that this is the
-> > > right thing to do.  The filesystem has a get_unmapped_area() which
+> > > right thing to do.A A The filesystem has a get_unmapped_area() which
 > > > should be used instead.
 > >
 > > Yes, I considered adding a filesystem entry point, but decided going
 > > this way because:
-> >  - arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are
-> > arch-specific code.  Therefore, this filesystem entry point will need
-> > arch-specific implementation. 
-> >  - There is nothing filesystem specific about requesting PMD alignment.
+> > A -A arch_get_unmapped_area() andA arch_get_unmapped_area_topdown() are
+> > arch-specific code. A Therefore, this filesystem entry point will need
+> > arch-specific implementation.A 
+> > A - There is nothing filesystem specific about requesting PMD alignment.
 >
 > See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's
-> approach for shmem.  I strongly believe that if we're going to do this
+> approach for shmem.A A I strongly believe that if we're going to do this
 > i the kernel, we should build on this approach, and not hack something
 > into each architecture's generic get_unmapped_area.
 
-Thanks for the pointer.  Yes, we can call current->mm->get_unmapped_area()
+Thanks for the pointer. A Yes, we can call current->mm->get_unmapped_area()
 with size + PMD_SIZE, and adjust with the alignment in a filesystem entry
-point.  I will update the patch with this approach.
+point. A I will update the patch with this approach.
 
 -Toshi
-_______________________________________________
-Linux-nvdimm mailing list
-Linux-nvdimm@lists.01.org
-https://lists.01.org/mailman/listinfo/linux-nvdimm
+
+--
+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 bf01a8a..e52bb8f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,15 +6,16 @@
  "Subject\0Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap\0"
  "Date\0Thu, 07 Apr 2016 15:20:33 -0600\0"
  "To\0Matthew Wilcox <willy@linux.intel.com>\0"
- "Cc\0linux-nvdimm@lists.01.org"
-  x86@kernel.org
-  linux-kernel@vger.kernel.org
-  mingo@kernel.org
-  linux-mm@kvack.org
+ "Cc\0mingo@kernel.org"
+  bp@suse.de
   hpa@zytor.com
   tglx@linutronix.de
-  bp@suse.de
- " kirill.shutemov@linux.intel.com\0"
+  dan.j.williams@intel.com
+  kirill.shutemov@linux.intel.com
+  linux-mm@kvack.org
+  x86@kernel.org
+  linux-nvdimm@lists.01.org
+ " linux-kernel@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote:\n"
@@ -24,47 +25,49 @@
  "> > > address without any kernel code.\n"
  "> >\n"
  "> > An application like NVML can continue to specify a specific address to\n"
- "> > mmap(). \302\240Most existing applications, however, do not specify an address\n"
- "> > to mmap(). \302\240With this patch, specifying an address will remain\n"
+ "> > mmap(). A Most existing applications, however, do not specify an address\n"
+ "> > to mmap(). A With this patch, specifying an address will remain\n"
  "> > optional.\n"
  ">\n"
- "> The point is that this *can* be done in userspace.\302\240\302\240You need to sell us\n"
+ "> The point is that this *can* be done in userspace.A A You need to sell us\n"
  "> on the advantages of doing it in the kernel.\n"
  "\n"
- "Sure. \302\240As I said, the point is that we do not need to modify existing\n"
+ "Sure. A As I said, the point is that we do not need to modify existing\n"
  "applications for using DAX PMD mappings.\n"
  "\n"
  "For instance, fio with \"ioengine=mmap\" performs I/Os with mmap().\n"
  "https://github.com/caius/fio/blob/master/engines/mmap.c\n"
  "\n"
  "With this change, unmodified fio can be used for testing with DAX PMD\n"
- "mappings. \302\240There are many examples like this, and I do not think we want to\n"
+ "mappings. A There are many examples like this, and I do not think we want to\n"
  "modify all applications that we want to evaluate/test with.\n"
  "\n"
  "> > > I think this is the wrong place for it, if we decide that this is the\n"
- "> > > right thing to do.\302\240\302\240The filesystem has a get_unmapped_area() which\n"
+ "> > > right thing to do.A A The filesystem has a get_unmapped_area() which\n"
  "> > > should be used instead.\n"
  "> >\n"
  "> > Yes, I considered adding a filesystem entry point, but decided going\n"
  "> > this way because:\n"
- "> > \302\240-\302\240arch_get_unmapped_area() and\302\240arch_get_unmapped_area_topdown() are\n"
- "> > arch-specific code. \302\240Therefore, this filesystem entry point will need\n"
- "> > arch-specific implementation.\302\240\n"
- "> > \302\240- There is nothing filesystem specific about requesting PMD alignment.\n"
+ "> > A -A arch_get_unmapped_area() andA arch_get_unmapped_area_topdown() are\n"
+ "> > arch-specific code. A Therefore, this filesystem entry point will need\n"
+ "> > arch-specific implementation.A \n"
+ "> > A - There is nothing filesystem specific about requesting PMD alignment.\n"
  ">\n"
  "> See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's\n"
- "> approach for shmem.\302\240\302\240I strongly believe that if we're going to do this\n"
+ "> approach for shmem.A A I strongly believe that if we're going to do this\n"
  "> i the kernel, we should build on this approach, and not hack something\n"
  "> into each architecture's generic get_unmapped_area.\n"
  "\n"
- "Thanks for the pointer. \302\240Yes, we can call current->mm->get_unmapped_area()\n"
+ "Thanks for the pointer. A Yes, we can call current->mm->get_unmapped_area()\n"
  "with size + PMD_SIZE, and adjust with the alignment in a filesystem entry\n"
- "point. \302\240I will update the patch with this approach.\n"
+ "point. A I will update the patch with this approach.\n"
  "\n"
  "-Toshi\n"
- "_______________________________________________\n"
- "Linux-nvdimm mailing list\n"
- "Linux-nvdimm@lists.01.org\n"
- https://lists.01.org/mailman/listinfo/linux-nvdimm
+ "\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>"
 
-5e554a205bc4b2182716de17bf76c197c5ca561c44f4da29c9eef1f353bbeb4a
+8d43f020f280f076faeb242bb78ec78cedc08d8a9beb332340653a5c91d69a54
