diff for duplicates of <1491928005.2654.6.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index 6b4b677..4bf31ab 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -9,16 +9,19 @@ 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 still +which intervals should the blk-mq core check whether or not a queue is stil= +l 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 immediately -after path initialization has finished. Sorry but I don't think it is possible +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 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. +Bart.= diff --git a/a/content_digest b/N1/content_digest index 56841ae..f35a791 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -22,18 +22,21 @@ "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 still\n" + "which intervals should the blk-mq core check whether or not a queue is stil=\n" + "l\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 immediately\n" - "after path initialization has finished. Sorry but I don't think it is possible\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" "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.= -75f9ff28bce4eeede83c416c0be33eea85cf056e13b40babc30c340a771db293 +0d121020367288dc9da1fa4882a0d6e029192ddf8c0e5125812615ec32638bdb
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.