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

diff --git a/a/1.txt b/N1/1.txt
index e8e82d7..f3d93e6 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,26 +1,39 @@
-T24gRnJpLCAyMDE3LTA1LTA1IGF0IDE1OjI1IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+
-IE9uIEZyaSwgTWF5IDUsIDIwMTcgYXQgMTozOSBQTSwgS2FuaSwgVG9zaGltaXRzdSA8dG9zaGku
-a2FuaUBocGUuY29tPg0KPiB3cm90ZToNCiA6DQo+ID4gPiAtLS0NCj4gPiA+IENoYW5nZXMgc2lu
-Y2UgdGhlIGluaXRpYWwgUkZDOg0KPiA+ID4gKiBzL3dyaXRldGhydS93dC8gc2luY2Ugd2UgYWxy
-ZWFkeSBoYXZlIGlvcmVtYXBfd3QoKSwNCj4gPiA+IHNldF9tZW1vcnlfd3QoKSwgZXRjLiAoSW5n
-bykNCj4gPiANCj4gPiBTb3JyeSBJIHNob3VsZCBoYXZlIHNhaWQgZWFybGllciwgYnV0IEkgdGhp
-bmsgdGhlIHRlcm0gInd0IiBpcw0KPiA+IG1pc2xlYWRpbmcuwqDCoE5vbi10ZW1wb3JhbCBzdG9y
-ZXMgdXNlZCBpbiBtZW1jcHlfd3QoKSBwcm92aWRlIFdDDQo+ID4gc2VtYW50aWNzLCBub3QgV1Qg
-c2VtYW50aWNzLg0KPiANCj4gVGhlIG5vbi10ZW1wb3JhbCBzdG9yZXMgZG8sIGJ1dCBtZW1jcHlf
-d3QoKSBpcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mDQo+IG5vbi10ZW1wb3JhbCBzdG9yZXMgYW5k
-IGV4cGxpY2l0IGNhY2hlIGZsdXNoaW5nLg0KPiANCj4gPiBIb3cgYWJvdXQgdXNpbmcgIm5vY2Fj
-aGUiIGFzIGl0J3MgYmVlbg0KPiA+IHVzZWQgaW4gX19jb3B5X3VzZXJfbm9jYWNoZSgpPw0KPiAN
-Cj4gVGhlIGRpZmZlcmVuY2UgaW4gbXkgbWluZCBpcyB0aGF0IHRoZSAiX25vY2FjaGUiIHN1ZmZp
-eCBpbmRpY2F0ZXMNCj4gb3Bwb3J0dW5pc3RpYyAvIG9wdGlvbmFsIGNhY2hlIHBvbGx1dGlvbiBh
-dm9pZGFuY2Ugd2hlcmVhcyAiX3d0Ig0KPiBzdHJpY3RseSBhcnJhbmdlcyBmb3IgY2FjaGVzIG5v
-dCB0byBjb250YWluIGRpcnR5IGRhdGEgdXBvbg0KPiBjb21wbGV0aW9uIG9mIHRoZSByb3V0aW5l
-LiBGb3IgZXhhbXBsZSwgbm9uLXRlbXBvcmFsIHN0b3JlcyBvbiBvbGRlcg0KPiB4ODYgY3B1cyBj
-b3VsZCBwb3RlbnRpYWxseSBsZWF2ZSBkaXJ0eSBkYXRhIGluIHRoZSBjYWNoZSwgc28NCj4gbWVt
-Y3B5X3d0IG9uIHRob3NlIGNwdXMgd291bGQgbmVlZCB0byB1c2UgZXhwbGljaXQgY2FjaGUgZmx1
-c2hpbmcuDQoNCkkgc2VlLiAgSSBhZ3JlZSB0aGF0IGl0cyBiZWhhdmlvciBpcyBkaWZmZXJlbnQg
-ZnJvbSB0aGUgZXhpc3Rpbmcgb25lDQp3aXRoICJfbm9jYWNoZSIuICAgVGhhdCBzYWlkLCBJIHRo
-aW5rICJ3dCIgb3IgIndyaXRlLXRocm91Z2giIGdlbmVyYWxseQ0KbWVhbnMgdGhhdCB3cml0ZXMg
-YWxsb2NhdGUgY2FjaGVsaW5lcyBhbmQga2VlcCB0aGVtIGNsZWFuIGJ5IHdyaXRpbmcgdG8NCm1l
-bW9yeS4gIFNvLCBzdWJzZXF1ZW50IHJlYWRzIHRvIHRoZSBkZXN0aW5hdGlvbiB3aWxsIGhpdCB0
-aGUNCmNhY2hlbGluZXMuICBUaGlzIGlzIG5vdCB0aGUgY2FzZSB3aXRoIHRoaXMgaW50ZXJmYWNl
-Lg0KDQpUaGFua3MsDQotVG9zaGkNCiA=
+On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote:
+> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu <toshi.kani@hpe.com>
+> wrote:
+ :
+> > > ---
+> > > Changes since the initial RFC:
+> > > * s/writethru/wt/ since we already have ioremap_wt(),
+> > > set_memory_wt(), etc. (Ingo)
+> > 
+> > Sorry I should have said earlier, but I think the term "wt" is
+> > misleading.  Non-temporal stores used in memcpy_wt() provide WC
+> > semantics, not WT semantics.
+> 
+> The non-temporal stores do, but memcpy_wt() is using a combination of
+> non-temporal stores and explicit cache flushing.
+> 
+> > How about using "nocache" as it's been
+> > used in __copy_user_nocache()?
+> 
+> The difference in my mind is that the "_nocache" suffix indicates
+> opportunistic / optional cache pollution avoidance whereas "_wt"
+> strictly arranges for caches not to contain dirty data upon
+> completion of the routine. For example, non-temporal stores on older
+> x86 cpus could potentially leave dirty data in the cache, so
+> memcpy_wt on those cpus would need to use explicit cache flushing.
+
+I see.  I agree that its behavior is different from the existing one
+with "_nocache".   That said, I think "wt" or "write-through" generally
+means that writes allocate cachelines and keep them clean by writing to
+memory.  So, subsequent reads to the destination will hit the
+cachelines.  This is not the case with this interface.
+
+Thanks,
+-Toshi
+ 
+_______________________________________________
+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 f246eec..86e2a56 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,47 +6,58 @@
  "Subject\0Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations\0"
  "Date\0Fri, 5 May 2017 22:44:40 +0000\0"
  "To\0dan.j.williams@intel.com <dan.j.williams@intel.com>\0"
- "Cc\0linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>"
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
-  jmoyer@redhat.com <jmoyer@redhat.com>
-  tglx@linutronix.de <tglx@linutronix.de>
-  hch@lst.de <hch@lst.de>
-  viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk>
-  x86@kernel.org <x86@kernel.org>
+ "Cc\0jack@suse.cz <jack@suse.cz>"
   mawilcox@microsoft.com <mawilcox@microsoft.com>
-  hpa@zytor.com <hpa@zytor.com>
+  x86@kernel.org <x86@kernel.org>
+  linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
+  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
   linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org>
   mingo@redhat.com <mingo@redhat.com>
+  viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk>
+  hpa@zytor.com <hpa@zytor.com>
   linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
-  ross.zwisler@linux.intel.com <ross.zwisler@linux.intel.com>
- " jack@suse.cz <jack@suse.cz>\0"
+  tglx@linutronix.de <tglx@linutronix.de>
+ " hch@lst.de <hch@lst.de>\0"
  "\00:1\0"
  "b\0"
- "T24gRnJpLCAyMDE3LTA1LTA1IGF0IDE1OjI1IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+\n"
- "IE9uIEZyaSwgTWF5IDUsIDIwMTcgYXQgMTozOSBQTSwgS2FuaSwgVG9zaGltaXRzdSA8dG9zaGku\n"
- "a2FuaUBocGUuY29tPg0KPiB3cm90ZToNCiA6DQo+ID4gPiAtLS0NCj4gPiA+IENoYW5nZXMgc2lu\n"
- "Y2UgdGhlIGluaXRpYWwgUkZDOg0KPiA+ID4gKiBzL3dyaXRldGhydS93dC8gc2luY2Ugd2UgYWxy\n"
- "ZWFkeSBoYXZlIGlvcmVtYXBfd3QoKSwNCj4gPiA+IHNldF9tZW1vcnlfd3QoKSwgZXRjLiAoSW5n\n"
- "bykNCj4gPiANCj4gPiBTb3JyeSBJIHNob3VsZCBoYXZlIHNhaWQgZWFybGllciwgYnV0IEkgdGhp\n"
- "bmsgdGhlIHRlcm0gInd0IiBpcw0KPiA+IG1pc2xlYWRpbmcuwqDCoE5vbi10ZW1wb3JhbCBzdG9y\n"
- "ZXMgdXNlZCBpbiBtZW1jcHlfd3QoKSBwcm92aWRlIFdDDQo+ID4gc2VtYW50aWNzLCBub3QgV1Qg\n"
- "c2VtYW50aWNzLg0KPiANCj4gVGhlIG5vbi10ZW1wb3JhbCBzdG9yZXMgZG8sIGJ1dCBtZW1jcHlf\n"
- "d3QoKSBpcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mDQo+IG5vbi10ZW1wb3JhbCBzdG9yZXMgYW5k\n"
- "IGV4cGxpY2l0IGNhY2hlIGZsdXNoaW5nLg0KPiANCj4gPiBIb3cgYWJvdXQgdXNpbmcgIm5vY2Fj\n"
- "aGUiIGFzIGl0J3MgYmVlbg0KPiA+IHVzZWQgaW4gX19jb3B5X3VzZXJfbm9jYWNoZSgpPw0KPiAN\n"
- "Cj4gVGhlIGRpZmZlcmVuY2UgaW4gbXkgbWluZCBpcyB0aGF0IHRoZSAiX25vY2FjaGUiIHN1ZmZp\n"
- "eCBpbmRpY2F0ZXMNCj4gb3Bwb3J0dW5pc3RpYyAvIG9wdGlvbmFsIGNhY2hlIHBvbGx1dGlvbiBh\n"
- "dm9pZGFuY2Ugd2hlcmVhcyAiX3d0Ig0KPiBzdHJpY3RseSBhcnJhbmdlcyBmb3IgY2FjaGVzIG5v\n"
- "dCB0byBjb250YWluIGRpcnR5IGRhdGEgdXBvbg0KPiBjb21wbGV0aW9uIG9mIHRoZSByb3V0aW5l\n"
- "LiBGb3IgZXhhbXBsZSwgbm9uLXRlbXBvcmFsIHN0b3JlcyBvbiBvbGRlcg0KPiB4ODYgY3B1cyBj\n"
- "b3VsZCBwb3RlbnRpYWxseSBsZWF2ZSBkaXJ0eSBkYXRhIGluIHRoZSBjYWNoZSwgc28NCj4gbWVt\n"
- "Y3B5X3d0IG9uIHRob3NlIGNwdXMgd291bGQgbmVlZCB0byB1c2UgZXhwbGljaXQgY2FjaGUgZmx1\n"
- "c2hpbmcuDQoNCkkgc2VlLiAgSSBhZ3JlZSB0aGF0IGl0cyBiZWhhdmlvciBpcyBkaWZmZXJlbnQg\n"
- "ZnJvbSB0aGUgZXhpc3Rpbmcgb25lDQp3aXRoICJfbm9jYWNoZSIuICAgVGhhdCBzYWlkLCBJIHRo\n"
- "aW5rICJ3dCIgb3IgIndyaXRlLXRocm91Z2giIGdlbmVyYWxseQ0KbWVhbnMgdGhhdCB3cml0ZXMg\n"
- "YWxsb2NhdGUgY2FjaGVsaW5lcyBhbmQga2VlcCB0aGVtIGNsZWFuIGJ5IHdyaXRpbmcgdG8NCm1l\n"
- "bW9yeS4gIFNvLCBzdWJzZXF1ZW50IHJlYWRzIHRvIHRoZSBkZXN0aW5hdGlvbiB3aWxsIGhpdCB0\n"
- "aGUNCmNhY2hlbGluZXMuICBUaGlzIGlzIG5vdCB0aGUgY2FzZSB3aXRoIHRoaXMgaW50ZXJmYWNl\n"
- Lg0KDQpUaGFua3MsDQotVG9zaGkNCiA=
+ "On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote:\n"
+ "> On Fri, May 5, 2017 at 1:39 PM, Kani, Toshimitsu <toshi.kani@hpe.com>\n"
+ "> wrote:\n"
+ " :\n"
+ "> > > ---\n"
+ "> > > Changes since the initial RFC:\n"
+ "> > > * s/writethru/wt/ since we already have ioremap_wt(),\n"
+ "> > > set_memory_wt(), etc. (Ingo)\n"
+ "> > \n"
+ "> > Sorry I should have said earlier, but I think the term \"wt\" is\n"
+ "> > misleading.\302\240\302\240Non-temporal stores used in memcpy_wt() provide WC\n"
+ "> > semantics, not WT semantics.\n"
+ "> \n"
+ "> The non-temporal stores do, but memcpy_wt() is using a combination of\n"
+ "> non-temporal stores and explicit cache flushing.\n"
+ "> \n"
+ "> > How about using \"nocache\" as it's been\n"
+ "> > used in __copy_user_nocache()?\n"
+ "> \n"
+ "> The difference in my mind is that the \"_nocache\" suffix indicates\n"
+ "> opportunistic / optional cache pollution avoidance whereas \"_wt\"\n"
+ "> strictly arranges for caches not to contain dirty data upon\n"
+ "> completion of the routine. For example, non-temporal stores on older\n"
+ "> x86 cpus could potentially leave dirty data in the cache, so\n"
+ "> memcpy_wt on those cpus would need to use explicit cache flushing.\n"
+ "\n"
+ "I see.  I agree that its behavior is different from the existing one\n"
+ "with \"_nocache\".   That said, I think \"wt\" or \"write-through\" generally\n"
+ "means that writes allocate cachelines and keep them clean by writing to\n"
+ "memory.  So, subsequent reads to the destination will hit the\n"
+ "cachelines.  This is not the case with this interface.\n"
+ "\n"
+ "Thanks,\n"
+ "-Toshi\n"
+ " \n"
+ "_______________________________________________\n"
+ "Linux-nvdimm mailing list\n"
+ "Linux-nvdimm@lists.01.org\n"
+ https://lists.01.org/mailman/listinfo/linux-nvdimm
 
-144389b513521a487b593790c86f201eb0ab180ccec4fd2318961c658d39e2fb
+4e4ed4983d0028dce15bf82ddd0d9032144af3d269496ef2dfae038246668c6f
