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

diff --git a/a/1.txt b/N1/1.txt
index 9f56d0c..48cad1c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,33 +2,33 @@ On Wed, 2016-04-06 at 12:50 -0400, Matthew Wilcox wrote:
 > On Wed, Apr 06, 2016 at 07:58:09AM -0600, Toshi Kani wrote:
 > > 
 > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using PMD page
-> > size.  This feature relies on both mmap virtual address and FS
+> > size.A A This feature relies on both mmap virtual address and FS
 > > block data (i.e. physical address) to be aligned by the PMD page
-> > size.  Users can use mkfs options to specify FS to align block
-> > allocations.  However, aligning mmap() address requires application
+> > size.A A Users can use mkfs options to specify FS to align block
+> > allocations.A A However, aligning mmap() address requires application
 > > changes to mmap() calls, such as:
 > > 
-> >  -  /* let the kernel to assign a mmap addr */
-> >  -  mptr = mmap(NULL, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);
+> > A -A A /* let the kernel to assign a mmap addr */
+> > A -A A mptr = mmap(NULL, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);
 > > 
-> >  +  /* 1. obtain a PMD-aligned virtual address */
-> >  +  ret = posix_memalign(&mptr, PMD_SIZE, fsize);
-> >  +  if (!ret)
-> >  +    free(mptr);  /* 2. release the virt addr */
-> >  +
-> >  +  /* 3. then pass the PMD-aligned virt addr to mmap() */
-> >  +  mptr = mmap(mptr, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);
+> > A +A A /* 1. obtain a PMD-aligned virtual address */
+> > A +A A ret = posix_memalign(&mptr, PMD_SIZE, fsize);
+> > A +A A if (!ret)
+> > A +A A A A free(mptr);A A /* 2. release the virt addr */
+> > A +
+> > A +A A /* 3. then pass the PMD-aligned virt addr to mmap() */
+> > A +A A mptr = mmap(mptr, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);
 > > 
 > > These changes add unnecessary dependency to DAX and PMD page size
-> > into application code.  The kernel should assign a mmap address
+> > into application code.A A The kernel should assign a mmap address
 > > appropriate for the operation.
 >
-> I question the need for this patch.  Choosing an appropriate base address
+> I question the need for this patch.A A Choosing an appropriate base address
 > is the least of the changes needed for an application to take advantage
-> of DAX.  
+> of DAX.A A 
 
 An application also needs to make sure that a given range [base -
-base+size] is free in VMA.  The above example uses posix_memalign() to find
+base+size] is free in VMA. A The above example uses posix_memalign() to find
 such a range, which in turn calls mmap() with size as (fsize + PMD_SIZE) in
 this case.
 
@@ -36,44 +36,44 @@ this case.
 > 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 optional.
+mmap(). A Most existing applications, however, do not specify an address to
+mmap(). A With this patch, specifying an address will remain optional.
 
 > > Change arch_get_unmapped_area() and arch_get_unmapped_area_topdown()
 > > to request PMD_SIZE alignment when the request is for a DAX file and
 > > its mapping range is large enough for using a PMD page.
 >
 > 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.
 
 > > 
 > > @@ -157,6 +157,13 @@ arch_get_unmapped_area(struct file *filp, unsigned
 > > long addr,
-> >  		info.align_mask = get_align_mask();
-> >  		info.align_offset += get_align_bits();
-> >  	}
+> > A 		info.align_mask = get_align_mask();
+> > A 		info.align_offset += get_align_bits();
+> > A 	}
 > > +	if (filp && IS_ENABLED(CONFIG_FS_DAX_PMD) &&
 > > IS_DAX(file_inode(filp))) {
 >
-> And there's never a need for the IS_ENABLED.  IS_DAX() compiles to '0' if
+> And there's never a need for the IS_ENABLED.A A IS_DAX() compiles to '0' if
 > CONFIG_FS_DAX is disabled.
 
 CONFIG_FS_DAX_PMD can be disabled while CONFIG_FS_DAX is enabled.
 
-> And where would this end?  Would you also change this code to look for
-> 1GB entries if CONFIG_FS_DAX_PUD is enabled?  Far better to have this
+> And where would this end?A A Would you also change this code to look for
+> 1GB entries if CONFIG_FS_DAX_PUD is enabled?A A Far better to have this
 > in the individual filesystem (probably calling a common helper in the DAX
 > code).
 
-Yes, it can be easily extended to support PUD.  This avoids another round
+Yes, it can be easily extended to support PUD. A This avoids another round
 of application changes to align with the PUD size.
 
 If the PUD support turns out to be filesystem specific, we may need a
@@ -81,7 +81,9 @@ capability bit in addition to CONFIG_FS_DAX_PUD.
 
 Thanks,
 -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 2a38df8..f3d4911 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,48 +4,49 @@
  "Subject\0Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap\0"
  "Date\0Wed, 06 Apr 2016 11:44:32 -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 Wed, 2016-04-06 at 12:50 -0400, Matthew Wilcox wrote:\n"
  "> On Wed, Apr 06, 2016 at 07:58:09AM -0600, Toshi Kani wrote:\n"
  "> > \n"
  "> > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using PMD page\n"
- "> > size.\302\240\302\240This feature relies on both mmap virtual address and FS\n"
+ "> > size.A A This feature relies on both mmap virtual address and FS\n"
  "> > block data (i.e. physical address) to be aligned by the PMD page\n"
- "> > size.\302\240\302\240Users can use mkfs options to specify FS to align block\n"
- "> > allocations.\302\240\302\240However, aligning mmap() address requires application\n"
+ "> > size.A A Users can use mkfs options to specify FS to align block\n"
+ "> > allocations.A A However, aligning mmap() address requires application\n"
  "> > changes to mmap() calls, such as:\n"
  "> > \n"
- "> > \302\240-\302\240\302\240/* let the kernel to assign a mmap addr */\n"
- "> > \302\240-\302\240\302\240mptr = mmap(NULL, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);\n"
+ "> > A -A A /* let the kernel to assign a mmap addr */\n"
+ "> > A -A A mptr = mmap(NULL, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);\n"
  "> > \n"
- "> > \302\240+\302\240\302\240/* 1. obtain a PMD-aligned virtual address */\n"
- "> > \302\240+\302\240\302\240ret = posix_memalign(&mptr, PMD_SIZE, fsize);\n"
- "> > \302\240+\302\240\302\240if (!ret)\n"
- "> > \302\240+\302\240\302\240\302\240\302\240free(mptr);\302\240\302\240/* 2. release the virt addr */\n"
- "> > \302\240+\n"
- "> > \302\240+\302\240\302\240/* 3. then pass the PMD-aligned virt addr to mmap() */\n"
- "> > \302\240+\302\240\302\240mptr = mmap(mptr, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);\n"
+ "> > A +A A /* 1. obtain a PMD-aligned virtual address */\n"
+ "> > A +A A ret = posix_memalign(&mptr, PMD_SIZE, fsize);\n"
+ "> > A +A A if (!ret)\n"
+ "> > A +A A A A free(mptr);A A /* 2. release the virt addr */\n"
+ "> > A +\n"
+ "> > A +A A /* 3. then pass the PMD-aligned virt addr to mmap() */\n"
+ "> > A +A A mptr = mmap(mptr, fsize, PROT_READ|PROT_WRITE, FLAGS, fd, 0);\n"
  "> > \n"
  "> > These changes add unnecessary dependency to DAX and PMD page size\n"
- "> > into application code.\302\240\302\240The kernel should assign a mmap address\n"
+ "> > into application code.A A The kernel should assign a mmap address\n"
  "> > appropriate for the operation.\n"
  ">\n"
- "> I question the need for this patch.\302\240\302\240Choosing an appropriate base address\n"
+ "> I question the need for this patch.A A Choosing an appropriate base address\n"
  "> is the least of the changes needed for an application to take advantage\n"
- "> of DAX.\302\240\302\240\n"
+ "> of DAX.A A \n"
  "\n"
  "An application also needs to make sure that a given range [base -\n"
- "base+size] is free in VMA. \302\240The above example uses posix_memalign() to find\n"
+ "base+size] is free in VMA. A The above example uses posix_memalign() to find\n"
  "such a range, which in turn calls mmap() with size as (fsize + PMD_SIZE) in\n"
  "this case.\n"
  "\n"
@@ -53,44 +54,44 @@
  "> 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 to\n"
- "mmap(). \302\240With this patch, specifying an address will remain optional.\n"
+ "mmap(). A Most existing applications, however, do not specify an address to\n"
+ "mmap(). A With this patch, specifying an address will remain optional.\n"
  "\n"
  "> > Change arch_get_unmapped_area() and arch_get_unmapped_area_topdown()\n"
  "> > to request PMD_SIZE alignment when the request is for a DAX file and\n"
  "> > its mapping range is large enough for using a PMD page.\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 this\n"
  "way because:\n"
- "\302\240-\302\240arch_get_unmapped_area() and\302\240arch_get_unmapped_area_topdown() are arch-\n"
- "specific code. \302\240Therefore, this filesystem entry point will need arch-\n"
- "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 arch-\n"
+ "specific code. A Therefore, this filesystem entry point will need arch-\n"
+ "specific implementation.A \n"
+ "A - There is nothing filesystem specific about requesting PMD alignment.\n"
  "\n"
  "> > \n"
  "> > @@ -157,6 +157,13 @@ arch_get_unmapped_area(struct file *filp, unsigned\n"
  "> > long addr,\n"
- "> > \302\240\t\tinfo.align_mask = get_align_mask();\n"
- "> > \302\240\t\tinfo.align_offset += get_align_bits();\n"
- "> > \302\240\t}\n"
+ "> > A \t\tinfo.align_mask = get_align_mask();\n"
+ "> > A \t\tinfo.align_offset += get_align_bits();\n"
+ "> > A \t}\n"
  "> > +\tif (filp && IS_ENABLED(CONFIG_FS_DAX_PMD) &&\n"
  "> > IS_DAX(file_inode(filp))) {\n"
  ">\n"
- "> And there's never a need for the IS_ENABLED.\302\240\302\240IS_DAX() compiles to '0' if\n"
+ "> And there's never a need for the IS_ENABLED.A A IS_DAX() compiles to '0' if\n"
  "> CONFIG_FS_DAX is disabled.\n"
  "\n"
  "CONFIG_FS_DAX_PMD can be disabled while CONFIG_FS_DAX is enabled.\n"
  "\n"
- "> And where would this end?\302\240\302\240Would you also change this code to look for\n"
- "> 1GB entries if CONFIG_FS_DAX_PUD is enabled?\302\240\302\240Far better to have this\n"
+ "> And where would this end?A A Would you also change this code to look for\n"
+ "> 1GB entries if CONFIG_FS_DAX_PUD is enabled?A A Far better to have this\n"
  "> in the individual filesystem (probably calling a common helper in the DAX\n"
  "> code).\n"
  "\n"
- "Yes, it can be easily extended to support PUD. \302\240This avoids another round\n"
+ "Yes, it can be easily extended to support PUD. A This avoids another round\n"
  "of application changes to align with the PUD size.\n"
  "\n"
  "If the PUD support turns out to be filesystem specific, we may need a\n"
@@ -98,9 +99,11 @@
  "\n"
  "Thanks,\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>"
 
-5b07e1cc4df361457ed0220a43b3b89edca05a23767f716180906989fa5faabb
+2f441d9f10f263f1d70fca15c251eb0342d2e9ad45a038af55bc2b6e13c366c8
