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

diff for duplicates of <1491928005.2654.6.camel@sandisk.com>

diff --git a/a/1.txt b/N1/1.txt
index 359486c..69823c2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -9,19 +9,16 @@ Hello Mike,
 If the blk-mq core would have to figure out whether or not a queue is no
 longer busy without any cooperation from the blk-mq driver all the blk-mq
 core could do is to attempt to rerun that queue from time to time. But at
-which intervals should the blk-mq core check whether or not a queue is stil=
-l
+which intervals should the blk-mq core check whether or not a queue is still
 busy? Would it be possible to choose intervals at which to check the queue
 state that work well for all block drivers? Consider e.g. at the dm-mpath
 driver. multipath_busy() returns true as long as path initialization is in
 progress. Path initialization can take a long time. The (indirect) call to
-blk_mq_run_queue() from pg_init_done() resumes request processing immediate=
-ly
-after path initialization has finished. Sorry but I don't think it is possi=
-ble
+blk_mq_run_queue() from pg_init_done() resumes request processing immediately
+after path initialization has finished. Sorry but I don't think it is possible
 to invent an algorithm for the blk-mq core that guarantees not only that a
 queue is rerun as soon as it is no longer busy but also that avoids that
 plenty of CPU cycles are wasted by the blk-mq core for checking whether a
 queue is no longer busy.
 
-Bart.=
\ No newline at end of file
+Bart.
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index ee08224..0f79694 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -43,22 +43,19 @@
   "If the blk-mq core would have to figure out whether or not a queue is no\n",
   "longer busy without any cooperation from the blk-mq driver all the blk-mq\n",
   "core could do is to attempt to rerun that queue from time to time. But at\n",
-  "which intervals should the blk-mq core check whether or not a queue is stil=\n",
-  "l\n",
+  "which intervals should the blk-mq core check whether or not a queue is still\n",
   "busy? Would it be possible to choose intervals at which to check the queue\n",
   "state that work well for all block drivers? Consider e.g. at the dm-mpath\n",
   "driver. multipath_busy() returns true as long as path initialization is in\n",
   "progress. Path initialization can take a long time. The (indirect) call to\n",
-  "blk_mq_run_queue() from pg_init_done() resumes request processing immediate=\n",
-  "ly\n",
-  "after path initialization has finished. Sorry but I don't think it is possi=\n",
-  "ble\n",
+  "blk_mq_run_queue() from pg_init_done() resumes request processing immediately\n",
+  "after path initialization has finished. Sorry but I don't think it is possible\n",
   "to invent an algorithm for the blk-mq core that guarantees not only that a\n",
   "queue is rerun as soon as it is no longer busy but also that avoids that\n",
   "plenty of CPU cycles are wasted by the blk-mq core for checking whether a\n",
   "queue is no longer busy.\n",
   "\n",
-  "Bart.="
+  "Bart."
 ]
 
-0d121020367288dc9da1fa4882a0d6e029192ddf8c0e5125812615ec32638bdb
+75f9ff28bce4eeede83c416c0be33eea85cf056e13b40babc30c340a771db293
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.