All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20170406045950.GA12362@redhat.com>

diff --git a/a/1.txt b/N1/1.txt
index 6369b5d..7fb25d7 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -9,14 +9,14 @@ On Thu, Apr 06, 2017 at 11:22:12AM +0800, Figo.zhang wrote:
 > > device can only access and use memory allocated through this API. This
 > > effectively split the program address space into object allocated for the
 > > device and useable by the device and other regular memory (malloc, mmap
-> > of a file, share memory, a?|) only accessible by CPU (or in a very limited
+> > of a file, share memory, …) only accessible by CPU (or in a very limited
 > > way by a device by pinning memory).
 > >
 > > Allowing different isolated component of a program to use a device thus
 > > require duplication of the input data structure using device memory
 > > allocator. This is reasonable for simple data structure (array, grid,
-> > image, a?|) but this get extremely complex with advance data structure
-> > (list, tree, graph, a?|) that rely on a web of memory pointers. This is
+> > image, …) but this get extremely complex with advance data structure
+> > (list, tree, graph, …) that rely on a web of memory pointers. This is
 > > becoming a serious limitation on the kind of work load that can be
 > > offloaded to device like GPU.
 > >
@@ -84,10 +84,4 @@ Any valid address on the CPU is valid on the GPU, that's it really. The
 migration to device memory is orthogonal to the share address space.
 
 Cheers,
-JA(C)rA'me
-
---
-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>
+Jérôme
diff --git a/a/content_digest b/N1/content_digest
index 69c0c14..b7dbcfa 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -24,14 +24,14 @@
  "> > device can only access and use memory allocated through this API. This\n"
  "> > effectively split the program address space into object allocated for the\n"
  "> > device and useable by the device and other regular memory (malloc, mmap\n"
- "> > of a file, share memory, a?|) only accessible by CPU (or in a very limited\n"
+ "> > of a file, share memory, \342\200\246) only accessible by CPU (or in a very limited\n"
  "> > way by a device by pinning memory).\n"
  "> >\n"
  "> > Allowing different isolated component of a program to use a device thus\n"
  "> > require duplication of the input data structure using device memory\n"
  "> > allocator. This is reasonable for simple data structure (array, grid,\n"
- "> > image, a?|) but this get extremely complex with advance data structure\n"
- "> > (list, tree, graph, a?|) that rely on a web of memory pointers. This is\n"
+ "> > image, \342\200\246) but this get extremely complex with advance data structure\n"
+ "> > (list, tree, graph, \342\200\246) that rely on a web of memory pointers. This is\n"
  "> > becoming a serious limitation on the kind of work load that can be\n"
  "> > offloaded to device like GPU.\n"
  "> >\n"
@@ -99,12 +99,6 @@
  "migration to device memory is orthogonal to the share address space.\n"
  "\n"
  "Cheers,\n"
- "JA(C)rA'me\n"
- "\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>"
+ "J\303\251r\303\264me"
 
-08e294ceb7d3ffa63dc640966ed3044c9aa3537a4fff298c057b9f315f6abe97
+b3315ae308bab5982f39f5c04a12b40ad7c62db8e6c27794a4f499422a612d08

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.