All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1504199166.666.11.camel@gmx.de>

diff --git a/a/1.txt b/N1/1.txt
index 987ee06..8c4c328 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,7 +1,7 @@
 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
@@ -9,15 +9,14 @@ On Thu, 2017-08-31 at 15:42 +0100, Mel Gorman wrote:
 > > 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 wor=
-k
+> > 
+> 
+> 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.
 
 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. =C2=A0Can't really
+with evolution mail usage during that on spinning rust.  Can't really
 say for sure given this is not based on measurement.
 
-	-Mike=C2=A0
+	-Mike
diff --git a/a/content_digest b/N1/content_digest
index df35492..1a486b6 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -17,7 +17,7 @@
  "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"
@@ -25,17 +25,16 @@
  "> > 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 wor=\n"
- "k\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"
  "\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. =C2=A0Can't really\n"
+ "with evolution mail usage during that on spinning rust. \302\240Can't really\n"
  "say for sure given this is not based on measurement.\n"
  "\n"
- "\t-Mike=C2=A0"
+ "\t-Mike"
 
-20a4505a4dc543974a7d5be186c757509923148e04886c6596be2575f2907a6d
+063d936278edaec183d2f80ffebdef41f5f1cb67388155cb3f4f285ac2454e49

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.