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

diff --git a/a/1.txt b/N1/1.txt
index eb8d0f0..91fcfcb 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,11 +1,10 @@
 On Thu, 2017-08-31 at 19:12 +0200, Paolo Valente wrote:
-> > Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith <efault@gmx.de> h=
-a 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
@@ -13,28 +12,26 @@ a scritto:
 > >>> 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
->=20
+> 
+> 
 > Great!  Actually, when I found these bugs, I thought also about the
 > issues you told me you experienced with updatedb running.  But then I
 > forgot to tell you that these fixes might help.
 
 I'm going to actively test that, because that is every bit as
-infuriating as the evolution thing, only updatedb is nukable. =C2=A0In fact=
-,
+infuriating as the evolution thing, only updatedb is nukable.  In fact,
 it infuriated me to the point that it no longer has a crontab entry,
-runs only when I decide to run it. =C2=A0At this point, I'll be pretty
+runs only when I decide to run it.  At this point, I'll be pretty
 surprised if that rotten <naughty words> is still alive.
 
 	-Mike
diff --git a/a/content_digest b/N1/content_digest
index 25b44f5..37c03da 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -17,13 +17,12 @@
  "\00:1\0"
  "b\0"
  "On Thu, 2017-08-31 at 19:12 +0200, Paolo Valente wrote:\n"
- "> > Il giorno 31 ago 2017, alle ore 19:06, Mike Galbraith <efault@gmx.de> h=\n"
- "a 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"
@@ -31,30 +30,28 @@
  "> >>> 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"
  "> >\n"
- ">=20\n"
- ">=20\n"
+ "> \n"
+ "> \n"
  "> Great!  Actually, when I found these bugs, I thought also about the\n"
  "> issues you told me you experienced with updatedb running.  But then I\n"
  "> forgot to tell you that these fixes might help.\n"
  "\n"
  "I'm going to actively test that, because that is every bit as\n"
- "infuriating as the evolution thing, only updatedb is nukable. =C2=A0In fact=\n"
- ",\n"
+ "infuriating as the evolution thing, only updatedb is nukable. \302\240In fact,\n"
  "it infuriated me to the point that it no longer has a crontab entry,\n"
- "runs only when I decide to run it. =C2=A0At this point, I'll be pretty\n"
+ "runs only when I decide to run it. \302\240At this point, I'll be pretty\n"
  "surprised if that rotten <naughty words> is still alive.\n"
  "\n"
  "\t-Mike"
 
-b7034857fae37f99601361ea2cd37ddb315087285ef58302a98ef81d1285b160
+f66cdc511e4ebfdd28762e33f56213d2d63a6f79db5a6b2d2e2b48ce25ee2f14

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.