diff for duplicates of <1492381396.25766.43.camel@kernel.crashing.org>

diff --git a/a/1.txt b/N1/1.txt
index 29cb60d..cb2470d 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,4 +1,4 @@
-On Sun, 2017-04-16 at 08:44 -0700, Dan Williams wrote:
+On Sun, 2017-04-16@08:44 -0700, Dan Williams wrote:
 > The difference is that there was nothing fundamental in the core
 > design of pmem + DAX that prevented other archs from growing pmem
 > support.
@@ -20,7 +20,7 @@ between "normal" memory (which includes non-PCI pmem in some cases,
 it's an architecture choice I suppose) and "special device" (page flag
 ? pfn bit ? ... there are options).
 
-From there, we keep our existing fast path for the normal case.
+>From there, we keep our existing fast path for the normal case.
 
 For the special case, we need to provide a fast lookup mechanism
 (assuming we can't stash enough stuff in struct page or the pfn)
@@ -70,7 +70,7 @@ in the PCI infrastructure.
 > > this is a pretty specific optimization that mostly helps systems
 > > designed in specific ways -- not a general "everybody gets faster" type
 > > situation.) Get the cases working we know will work, can easily support
-> > and people actually want.  Then expand it to support others as people
+> > and people actually want.? Then expand it to support others as people
 > > come around with hardware to test and use cases for it.
 > 
 > I think you need to give other archs a chance to support this with a
@@ -90,8 +90,3 @@ powerpc bits but we need to agree on the design first :)
 
 Cheers,
 Ben.
-
-_______________________________________________
-Linux-nvdimm mailing list
-Linux-nvdimm@lists.01.org
-https://lists.01.org/mailman/listinfo/linux-nvdimm
diff --git a/a/content_digest b/N1/content_digest
index 63cb51b..9dd606e 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,29 +1,10 @@
  "ref\0CAPcyv4it56J8Voo6kV0bBcO3nHsOHYLENpAtONJZTGceDDwNPg@mail.gmail.com\0"
- "ref\0CAPcyv4it56J8Voo6kV0bBcO3nHsOHYLENpAtONJZTGceDDwNPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org\0"
- "From\0Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>\0"
- "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0"
+ "From\0benh@kernel.crashing.org (Benjamin Herrenschmidt)\0"
+ "Subject\0[RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0"
  "Date\0Mon, 17 Apr 2017 08:23:16 +1000\0"
- "To\0Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>"
- " Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>\0"
- "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>"
-  Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
-  James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
-  Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
-  linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
-  linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
-  Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
-  Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
-  Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
-  linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
-  linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org>
-  Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
- " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0"
  "\00:1\0"
  "b\0"
- "On Sun, 2017-04-16 at 08:44 -0700, Dan Williams wrote:\n"
+ "On Sun, 2017-04-16@08:44 -0700, Dan Williams wrote:\n"
  "> The difference is that there was nothing fundamental in the core\n"
  "> design of pmem + DAX that prevented other archs from growing pmem\n"
  "> support.\n"
@@ -45,7 +26,7 @@
  "it's an architecture choice I suppose) and \"special device\" (page flag\n"
  "? pfn bit ? ... there are options).\n"
  "\n"
- "From there, we keep our existing fast path for the normal case.\n"
+ ">From there, we keep our existing fast path for the normal case.\n"
  "\n"
  "For the special case, we need to provide a fast lookup mechanism\n"
  "(assuming we can't stash enough stuff in struct page or the pfn)\n"
@@ -95,7 +76,7 @@
  "> > this is a pretty specific optimization that mostly helps systems\n"
  "> > designed in specific ways -- not a general \"everybody gets faster\" type\n"
  "> > situation.) Get the cases working we know will work, can easily support\n"
- "> > and people actually want.\302\240 Then expand it to support others as people\n"
+ "> > and people actually want.? Then expand it to support others as people\n"
  "> > come around with hardware to test and use cases for it.\n"
  "> \n"
  "> I think you need to give other archs a chance to support this with a\n"
@@ -114,11 +95,6 @@
  "powerpc bits but we need to agree on the design first :)\n"
  "\n"
  "Cheers,\n"
- "Ben.\n"
- "\n"
- "_______________________________________________\n"
- "Linux-nvdimm mailing list\n"
- "Linux-nvdimm@lists.01.org\n"
- https://lists.01.org/mailman/listinfo/linux-nvdimm
+ Ben.
 
-2532c190afedf9cd05d7624e3dfd9883726248675297497eabf883df246eef94
+1b3ddf582e57bd1ae271e513c664ad9bf49ece07f23cde8d2774edabd04e66ac
