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

diff --git a/a/1.txt b/N1/1.txt
index c9e7fca..ccca3af 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,4 +1,4 @@
-On Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote:
+On Mon, 2017-04-17@10:52 -0600, Logan Gunthorpe wrote:
 > 
 > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote:
 > > But is it ? For example take a GPU, does it, in your scheme, need an
@@ -85,7 +85,7 @@ point.
 If we are going to create some sort of struct dma_target, HMM could
 potentially just look for the parent if it needs the PCI device.
 
-> > >  This amazingly gets us the get_dev_pagemap
+> > > ?This amazingly gets us the get_dev_pagemap
 > > > architecture which also uses a struct device. So by using a p2pmem
 > > > device we can go from struct page to struct device to p2pmem device
 > > > quickly and effortlessly.
@@ -125,7 +125,7 @@ I find actually confusing.
 > > That a device might have some memory-like buffer space is all well and
 > > good but does it need to be specifically distinguished at the device
 > > level ? It could be inherent to what the device is... for example again
-> > take the GPU example, why would you call the FB memory "p2pmem" ? 
+> > take the GPU example, why would you call the FB memory "p2pmem" ??
 > 
 > Well if you are using it for p2p transactions why wouldn't you call it
 > p2pmem?
@@ -142,7 +142,7 @@ see.
 
 > I can certainly see an issue you'd have with the current RFC in that the
 > p2pmem device currently also handles memory allocation which a GPU would
->  want to do itself.
+> ?want to do itself.
 
 The memory allocation should be a completely orthogonal and separate
 thing yes. You are conflating two completely different things now into
@@ -165,7 +165,7 @@ problems and solving them independently.
 > > it's the term "p2pmem" that offputs me. If p2pmem allowed to have a
 > > standard way to lookup the various offsets etc... I mentioned earlier,
 > > then yes, it would make sense to have it as a staging point. As-is, I
-> > don't know. 
+> > don't know.?
 > 
 > Well of course, at some point it would have a standard way to lookup
 > offsets and figure out what's necessary for a mapping. We wouldn't make
@@ -186,7 +186,3 @@ problems and solving them independently.
 > cases.
 > 
 > Logan
-_______________________________________________
-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 530943a..440e257 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,31 +4,12 @@
  "ref\06149ab5e-c981-6881-8c5a-22349561c3e8@deltatee.com\0"
  "ref\01492413640.25766.52.camel@kernel.crashing.org\0"
  "ref\0ac643c73-43e9-1658-ffcb-d5628f80cbc1@deltatee.com\0"
- "ref\0ac643c73-43e9-1658-ffcb-d5628f80cbc1-OTvnGxWRz7hWk0Htik3J/w@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\0Tue, 18 Apr 2017 07:11:37 +1000\0"
- "To\0Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>"
- " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@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 Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote:\n"
+ "On Mon, 2017-04-17@10:52 -0600, Logan Gunthorpe wrote:\n"
  "> \n"
  "> On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote:\n"
  "> > But is it ? For example take a GPU, does it, in your scheme, need an\n"
@@ -115,7 +96,7 @@
  "If we are going to create some sort of struct dma_target, HMM could\n"
  "potentially just look for the parent if it needs the PCI device.\n"
  "\n"
- "> > > \302\240This amazingly gets us the get_dev_pagemap\n"
+ "> > > ?This amazingly gets us the get_dev_pagemap\n"
  "> > > architecture which also uses a struct device. So by using a p2pmem\n"
  "> > > device we can go from struct page to struct device to p2pmem device\n"
  "> > > quickly and effortlessly.\n"
@@ -155,7 +136,7 @@
  "> > That a device might have some memory-like buffer space is all well and\n"
  "> > good but does it need to be specifically distinguished at the device\n"
  "> > level ? It could be inherent to what the device is... for example again\n"
- "> > take the GPU example, why would you call the FB memory \"p2pmem\" ?\302\240\n"
+ "> > take the GPU example, why would you call the FB memory \"p2pmem\" ??\n"
  "> \n"
  "> Well if you are using it for p2p transactions why wouldn't you call it\n"
  "> p2pmem?\n"
@@ -172,7 +153,7 @@
  "\n"
  "> I can certainly see an issue you'd have with the current RFC in that the\n"
  "> p2pmem device currently also handles memory allocation which a GPU would\n"
- "> \302\240want to do itself.\n"
+ "> ?want to do itself.\n"
  "\n"
  "The memory allocation should be a completely orthogonal and separate\n"
  "thing yes. You are conflating two completely different things now into\n"
@@ -195,7 +176,7 @@
  "> > it's the term \"p2pmem\" that offputs me. If p2pmem allowed to have a\n"
  "> > standard way to lookup the various offsets etc... I mentioned earlier,\n"
  "> > then yes, it would make sense to have it as a staging point. As-is, I\n"
- "> > don't know.\302\240\n"
+ "> > don't know.?\n"
  "> \n"
  "> Well of course, at some point it would have a standard way to lookup\n"
  "> offsets and figure out what's necessary for a mapping. We wouldn't make\n"
@@ -215,10 +196,6 @@
  "> alternative that provides the same features and potential for future use\n"
  "> cases.\n"
  "> \n"
- "> Logan\n"
- "_______________________________________________\n"
- "Linux-nvdimm mailing list\n"
- "Linux-nvdimm@lists.01.org\n"
- https://lists.01.org/mailman/listinfo/linux-nvdimm
+ > Logan
 
-65b8bdc43cb37ddcc56e4f7a47db7a4c9ab64d5fdffbeb112b2815c8805d7308
+6e9608181f031b1eaeaaddf7d4cca5e8a7396edc84d47ecfb6f2f42e9e3d439d
