All of lore.kernel.org
 help / color / mirror / Atom feed

diff for duplicates of <970115C1-6336-458D-BBD5-3E5054C4553D@linaro.org>

diff --git a/a/1.txt b/N1/1.txt
index d3e034f..9dbbdb3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,30 +1,27 @@
 
-> Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith <efault@gmx.de> =
-ha scritto:
->=20
+> Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith <efault@gmx.de> ha scritto:
+> 
 > On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote:
 >> On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote:
 >>> [SECOND TAKE, with just the name of one of the tester fixed]
->>>=20
+>>> 
 >>> Hi,
 >>> while testing the read-write unfairness issues reported by Mel, I
 >>> found BFQ failing to guarantee good responsiveness against heavy
 >>> random sync writes in the background, i.e., multiple writers doing
->>> random writes and systematic fdatasync [1]. The failure was caused =
-by
+>>> random writes and systematic fdatasync [1]. The failure was caused by
 >>> three related bugs, because of which BFQ failed to guarantee to
 >>> high-weight processes the expected fraction of the throughput.
->>>=20
->>=20
->> Queued on top of Ming's most recent series even though that's still a =
-work
+>>> 
+>> 
+>> Queued on top of Ming's most recent series even though that's still a work
 >> in progress. I should know in a few days how things stand.
->=20
+> 
 > It seems to have cured an interactivity issue I regularly meet during
 > kbuild final link/depmod phase of fat kernel kbuild, especially bad
 > with evolution mail usage during that on spinning rust.  Can't really
 > say for sure given this is not based on measurement.
->=20
+> 
 
 
 Great!  Actually, when I found these bugs, I thought also about the
@@ -34,4 +31,4 @@ forgot to tell you that these fixes might help.
 Thanks,
 Paolo
 
-> 	-Mike=20
\ No newline at end of file
+> 	-Mike
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 921c92f..95b51d7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -37,32 +37,29 @@
 ]
 [
   "\n",
-  "> Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith <efault\@gmx.de> =\n",
-  "ha scritto:\n",
-  ">=20\n",
+  "> Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith <efault\@gmx.de> ha scritto:\n",
+  "> \n",
   "> On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote:\n",
   ">> On Thu, Aug 31, 2017 at 08:46:28AM +0200, Paolo Valente wrote:\n",
   ">>> [SECOND TAKE, with just the name of one of the tester fixed]\n",
-  ">>>=20\n",
+  ">>> \n",
   ">>> Hi,\n",
   ">>> while testing the read-write unfairness issues reported by Mel, I\n",
   ">>> found BFQ failing to guarantee good responsiveness against heavy\n",
   ">>> random sync writes in the background, i.e., multiple writers doing\n",
-  ">>> random writes and systematic fdatasync [1]. The failure was caused =\n",
-  "by\n",
+  ">>> random writes and systematic fdatasync [1]. The failure was caused by\n",
   ">>> three related bugs, because of which BFQ failed to guarantee to\n",
   ">>> high-weight processes the expected fraction of the throughput.\n",
-  ">>>=20\n",
-  ">>=20\n",
-  ">> Queued on top of Ming's most recent series even though that's still a =\n",
-  "work\n",
+  ">>> \n",
+  ">> \n",
+  ">> Queued on top of Ming's most recent series even though that's still a work\n",
   ">> in progress. I should know in a few days how things stand.\n",
-  ">=20\n",
+  "> \n",
   "> It seems to have cured an interactivity issue I regularly meet during\n",
   "> kbuild final link/depmod phase of fat kernel kbuild, especially bad\n",
   "> with evolution mail usage during that on spinning rust.  Can't really\n",
   "> say for sure given this is not based on measurement.\n",
-  ">=20\n",
+  "> \n",
   "\n",
   "\n",
   "Great!  Actually, when I found these bugs, I thought also about the\n",
@@ -72,7 +69,7 @@
   "Thanks,\n",
   "Paolo\n",
   "\n",
-  "> \t-Mike=20"
+  "> \t-Mike"
 ]
 
-c1e10f590a9b6d5948aca8b1d5015862a01c6a10462f8a814daf1424023eda44
+c027b7e9b01a003dde78023dcdd88653c2836c6200535fe75a6288832fde0436
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.