bfq-iosched.rst 26 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590
  1. ==========================
  2. BFQ (Budget Fair Queueing)
  3. ==========================
  4. BFQ is a proportional-share I/O scheduler, with some extra
  5. low-latency capabilities. In addition to cgroups support (blkio or io
  6. controllers), BFQ's main features are:
  7. - BFQ guarantees a high system and application responsiveness, and a
  8. low latency for time-sensitive applications, such as audio or video
  9. players;
  10. - BFQ distributes bandwidth, and not just time, among processes or
  11. groups (switching back to time distribution when needed to keep
  12. throughput high).
  13. In its default configuration, BFQ privileges latency over
  14. throughput. So, when needed for achieving a lower latency, BFQ builds
  15. schedules that may lead to a lower throughput. If your main or only
  16. goal, for a given device, is to achieve the maximum-possible
  17. throughput at all times, then do switch off all low-latency heuristics
  18. for that device, by setting low_latency to 0. See Section 3 for
  19. details on how to configure BFQ for the desired tradeoff between
  20. latency and throughput, or on how to maximize throughput.
  21. As every I/O scheduler, BFQ adds some overhead to per-I/O-request
  22. processing. To give an idea of this overhead, the total,
  23. single-lock-protected, per-request processing time of BFQ---i.e., the
  24. sum of the execution times of the request insertion, dispatch and
  25. completion hooks---is, e.g., 1.9 us on an Intel Core i7-2760QM@2.40GHz
  26. (dated CPU for notebooks; time measured with simple code
  27. instrumentation, and using the throughput-sync.sh script of the S
  28. suite [1], in performance-profiling mode). To put this result into
  29. context, the total, single-lock-protected, per-request execution time
  30. of the lightest I/O scheduler available in blk-mq, mq-deadline, is 0.7
  31. us (mq-deadline is ~800 LOC, against ~10500 LOC for BFQ).
  32. Scheduling overhead further limits the maximum IOPS that a CPU can
  33. process (already limited by the execution of the rest of the I/O
  34. stack). To give an idea of the limits with BFQ, on slow or average
  35. CPUs, here are, first, the limits of BFQ for three different CPUs, on,
  36. respectively, an average laptop, an old desktop, and a cheap embedded
  37. system, in case full hierarchical support is enabled (i.e.,
  38. CONFIG_BFQ_GROUP_IOSCHED is set), but CONFIG_BFQ_CGROUP_DEBUG is not
  39. set (Section 4-2):
  40. - Intel i7-4850HQ: 400 KIOPS
  41. - AMD A8-3850: 250 KIOPS
  42. - ARM CortexTM-A53 Octa-core: 80 KIOPS
  43. If CONFIG_BFQ_CGROUP_DEBUG is set (and of course full hierarchical
  44. support is enabled), then the sustainable throughput with BFQ
  45. decreases, because all blkio.bfq* statistics are created and updated
  46. (Section 4-2). For BFQ, this leads to the following maximum
  47. sustainable throughputs, on the same systems as above:
  48. - Intel i7-4850HQ: 310 KIOPS
  49. - AMD A8-3850: 200 KIOPS
  50. - ARM CortexTM-A53 Octa-core: 56 KIOPS
  51. BFQ works for multi-queue devices too.
  52. .. The table of contents follow. Impatients can just jump to Section 3.
  53. .. CONTENTS
  54. 1. When may BFQ be useful?
  55. 1-1 Personal systems
  56. 1-2 Server systems
  57. 2. How does BFQ work?
  58. 3. What are BFQ's tunables and how to properly configure BFQ?
  59. 4. BFQ group scheduling
  60. 4-1 Service guarantees provided
  61. 4-2 Interface
  62. 1. When may BFQ be useful?
  63. ==========================
  64. BFQ provides the following benefits on personal and server systems.
  65. 1-1 Personal systems
  66. --------------------
  67. Low latency for interactive applications
  68. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  69. Regardless of the actual background workload, BFQ guarantees that, for
  70. interactive tasks, the storage device is virtually as responsive as if
  71. it was idle. For example, even if one or more of the following
  72. background workloads are being executed:
  73. - one or more large files are being read, written or copied,
  74. - a tree of source files is being compiled,
  75. - one or more virtual machines are performing I/O,
  76. - a software update is in progress,
  77. - indexing daemons are scanning filesystems and updating their
  78. databases,
  79. starting an application or loading a file from within an application
  80. takes about the same time as if the storage device was idle. As a
  81. comparison, with CFQ, NOOP or DEADLINE, and in the same conditions,
  82. applications experience high latencies, or even become unresponsive
  83. until the background workload terminates (also on SSDs).
  84. Low latency for soft real-time applications
  85. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  86. Also soft real-time applications, such as audio and video
  87. players/streamers, enjoy a low latency and a low drop rate, regardless
  88. of the background I/O workload. As a consequence, these applications
  89. do not suffer from almost any glitch due to the background workload.
  90. Higher speed for code-development tasks
  91. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  92. If some additional workload happens to be executed in parallel, then
  93. BFQ executes the I/O-related components of typical code-development
  94. tasks (compilation, checkout, merge, ...) much more quickly than CFQ,
  95. NOOP or DEADLINE.
  96. High throughput
  97. ^^^^^^^^^^^^^^^
  98. On hard disks, BFQ achieves up to 30% higher throughput than CFQ, and
  99. up to 150% higher throughput than DEADLINE and NOOP, with all the
  100. sequential workloads considered in our tests. With random workloads,
  101. and with all the workloads on flash-based devices, BFQ achieves,
  102. instead, about the same throughput as the other schedulers.
  103. Strong fairness, bandwidth and delay guarantees
  104. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  105. BFQ distributes the device throughput, and not just the device time,
  106. among I/O-bound applications in proportion their weights, with any
  107. workload and regardless of the device parameters. From these bandwidth
  108. guarantees, it is possible to compute tight per-I/O-request delay
  109. guarantees by a simple formula. If not configured for strict service
  110. guarantees, BFQ switches to time-based resource sharing (only) for
  111. applications that would otherwise cause a throughput loss.
  112. 1-2 Server systems
  113. ------------------
  114. Most benefits for server systems follow from the same service
  115. properties as above. In particular, regardless of whether additional,
  116. possibly heavy workloads are being served, BFQ guarantees:
  117. * audio and video-streaming with zero or very low jitter and drop
  118. rate;
  119. * fast retrieval of WEB pages and embedded objects;
  120. * real-time recording of data in live-dumping applications (e.g.,
  121. packet logging);
  122. * responsiveness in local and remote access to a server.
  123. 2. How does BFQ work?
  124. =====================
  125. BFQ is a proportional-share I/O scheduler, whose general structure,
  126. plus a lot of code, are borrowed from CFQ.
  127. - Each process doing I/O on a device is associated with a weight and a
  128. `(bfq_)queue`.
  129. - BFQ grants exclusive access to the device, for a while, to one queue
  130. (process) at a time, and implements this service model by
  131. associating every queue with a budget, measured in number of
  132. sectors.
  133. - After a queue is granted access to the device, the budget of the
  134. queue is decremented, on each request dispatch, by the size of the
  135. request.
  136. - The in-service queue is expired, i.e., its service is suspended,
  137. only if one of the following events occurs: 1) the queue finishes
  138. its budget, 2) the queue empties, 3) a "budget timeout" fires.
  139. - The budget timeout prevents processes doing random I/O from
  140. holding the device for too long and dramatically reducing
  141. throughput.
  142. - Actually, as in CFQ, a queue associated with a process issuing
  143. sync requests may not be expired immediately when it empties. In
  144. contrast, BFQ may idle the device for a short time interval,
  145. giving the process the chance to go on being served if it issues
  146. a new request in time. Device idling typically boosts the
  147. throughput on rotational devices and on non-queueing flash-based
  148. devices, if processes do synchronous and sequential I/O. In
  149. addition, under BFQ, device idling is also instrumental in
  150. guaranteeing the desired throughput fraction to processes
  151. issuing sync requests (see the description of the slice_idle
  152. tunable in this document, or [1, 2], for more details).
  153. - With respect to idling for service guarantees, if several
  154. processes are competing for the device at the same time, but
  155. all processes and groups have the same weight, then BFQ
  156. guarantees the expected throughput distribution without ever
  157. idling the device. Throughput is thus as high as possible in
  158. this common scenario.
  159. - On flash-based storage with internal queueing of commands
  160. (typically NCQ), device idling happens to be always detrimental
  161. for throughput. So, with these devices, BFQ performs idling
  162. only when strictly needed for service guarantees, i.e., for
  163. guaranteeing low latency or fairness. In these cases, overall
  164. throughput may be sub-optimal. No solution currently exists to
  165. provide both strong service guarantees and optimal throughput
  166. on devices with internal queueing.
  167. - If low-latency mode is enabled (default configuration), BFQ
  168. executes some special heuristics to detect interactive and soft
  169. real-time applications (e.g., video or audio players/streamers),
  170. and to reduce their latency. The most important action taken to
  171. achieve this goal is to give to the queues associated with these
  172. applications more than their fair share of the device
  173. throughput. For brevity, we call just "weight-raising" the whole
  174. sets of actions taken by BFQ to privilege these queues. In
  175. particular, BFQ provides a milder form of weight-raising for
  176. interactive applications, and a stronger form for soft real-time
  177. applications.
  178. - BFQ automatically deactivates idling for queues born in a burst of
  179. queue creations. In fact, these queues are usually associated with
  180. the processes of applications and services that benefit mostly
  181. from a high throughput. Examples are systemd during boot, or git
  182. grep.
  183. - As CFQ, BFQ merges queues performing interleaved I/O, i.e.,
  184. performing random I/O that becomes mostly sequential if
  185. merged. Differently from CFQ, BFQ achieves this goal with a more
  186. reactive mechanism, called Early Queue Merge (EQM). EQM is so
  187. responsive in detecting interleaved I/O (cooperating processes),
  188. that it enables BFQ to achieve a high throughput, by queue
  189. merging, even for queues for which CFQ needs a different
  190. mechanism, preemption, to get a high throughput. As such EQM is a
  191. unified mechanism to achieve a high throughput with interleaved
  192. I/O.
  193. - Queues are scheduled according to a variant of WF2Q+, named
  194. B-WF2Q+, and implemented using an augmented rb-tree to preserve an
  195. O(log N) overall complexity. See [2] for more details. B-WF2Q+ is
  196. also ready for hierarchical scheduling, details in Section 4.
  197. - B-WF2Q+ guarantees a tight deviation with respect to an ideal,
  198. perfectly fair, and smooth service. In particular, B-WF2Q+
  199. guarantees that each queue receives a fraction of the device
  200. throughput proportional to its weight, even if the throughput
  201. fluctuates, and regardless of: the device parameters, the current
  202. workload and the budgets assigned to the queue.
  203. - The last, budget-independence, property (although probably
  204. counterintuitive in the first place) is definitely beneficial, for
  205. the following reasons:
  206. - First, with any proportional-share scheduler, the maximum
  207. deviation with respect to an ideal service is proportional to
  208. the maximum budget (slice) assigned to queues. As a consequence,
  209. BFQ can keep this deviation tight not only because of the
  210. accurate service of B-WF2Q+, but also because BFQ *does not*
  211. need to assign a larger budget to a queue to let the queue
  212. receive a higher fraction of the device throughput.
  213. - Second, BFQ is free to choose, for every process (queue), the
  214. budget that best fits the needs of the process, or best
  215. leverages the I/O pattern of the process. In particular, BFQ
  216. updates queue budgets with a simple feedback-loop algorithm that
  217. allows a high throughput to be achieved, while still providing
  218. tight latency guarantees to time-sensitive applications. When
  219. the in-service queue expires, this algorithm computes the next
  220. budget of the queue so as to:
  221. - Let large budgets be eventually assigned to the queues
  222. associated with I/O-bound applications performing sequential
  223. I/O: in fact, the longer these applications are served once
  224. got access to the device, the higher the throughput is.
  225. - Let small budgets be eventually assigned to the queues
  226. associated with time-sensitive applications (which typically
  227. perform sporadic and short I/O), because, the smaller the
  228. budget assigned to a queue waiting for service is, the sooner
  229. B-WF2Q+ will serve that queue (Subsec 3.3 in [2]).
  230. - If several processes are competing for the device at the same time,
  231. but all processes and groups have the same weight, then BFQ
  232. guarantees the expected throughput distribution without ever idling
  233. the device. It uses preemption instead. Throughput is then much
  234. higher in this common scenario.
  235. - ioprio classes are served in strict priority order, i.e.,
  236. lower-priority queues are not served as long as there are
  237. higher-priority queues. Among queues in the same class, the
  238. bandwidth is distributed in proportion to the weight of each
  239. queue. A very thin extra bandwidth is however guaranteed to
  240. the Idle class, to prevent it from starving.
  241. 3. What are BFQ's tunables and how to properly configure BFQ?
  242. =============================================================
  243. Most BFQ tunables affect service guarantees (basically latency and
  244. fairness) and throughput. For full details on how to choose the
  245. desired tradeoff between service guarantees and throughput, see the
  246. parameters slice_idle, strict_guarantees and low_latency. For details
  247. on how to maximise throughput, see slice_idle, timeout_sync and
  248. max_budget. The other performance-related parameters have been
  249. inherited from, and have been preserved mostly for compatibility with
  250. CFQ. So far, no performance improvement has been reported after
  251. changing the latter parameters in BFQ.
  252. In particular, the tunables back_seek-max, back_seek_penalty,
  253. fifo_expire_async and fifo_expire_sync below are the same as in
  254. CFQ. Their description is just copied from that for CFQ. Some
  255. considerations in the description of slice_idle are copied from CFQ
  256. too.
  257. per-process ioprio and weight
  258. -----------------------------
  259. Unless the cgroups interface is used (see "4. BFQ group scheduling"),
  260. weights can be assigned to processes only indirectly, through I/O
  261. priorities, and according to the relation:
  262. weight = (IOPRIO_BE_NR - ioprio) * 10.
  263. Beware that, if low-latency is set, then BFQ automatically raises the
  264. weight of the queues associated with interactive and soft real-time
  265. applications. Unset this tunable if you need/want to control weights.
  266. slice_idle
  267. ----------
  268. This parameter specifies how long BFQ should idle for next I/O
  269. request, when certain sync BFQ queues become empty. By default
  270. slice_idle is a non-zero value. Idling has a double purpose: boosting
  271. throughput and making sure that the desired throughput distribution is
  272. respected (see the description of how BFQ works, and, if needed, the
  273. papers referred there).
  274. As for throughput, idling can be very helpful on highly seeky media
  275. like single spindle SATA/SAS disks where we can cut down on overall
  276. number of seeks and see improved throughput.
  277. Setting slice_idle to 0 will remove all the idling on queues and one
  278. should see an overall improved throughput on faster storage devices
  279. like multiple SATA/SAS disks in hardware RAID configuration, as well
  280. as flash-based storage with internal command queueing (and
  281. parallelism).
  282. So depending on storage and workload, it might be useful to set
  283. slice_idle=0. In general for SATA/SAS disks and software RAID of
  284. SATA/SAS disks keeping slice_idle enabled should be useful. For any
  285. configurations where there are multiple spindles behind single LUN
  286. (Host based hardware RAID controller or for storage arrays), or with
  287. flash-based fast storage, setting slice_idle=0 might end up in better
  288. throughput and acceptable latencies.
  289. Idling is however necessary to have service guarantees enforced in
  290. case of differentiated weights or differentiated I/O-request lengths.
  291. To see why, suppose that a given BFQ queue A must get several I/O
  292. requests served for each request served for another queue B. Idling
  293. ensures that, if A makes a new I/O request slightly after becoming
  294. empty, then no request of B is dispatched in the middle, and thus A
  295. does not lose the possibility to get more than one request dispatched
  296. before the next request of B is dispatched. Note that idling
  297. guarantees the desired differentiated treatment of queues only in
  298. terms of I/O-request dispatches. To guarantee that the actual service
  299. order then corresponds to the dispatch order, the strict_guarantees
  300. tunable must be set too.
  301. There is an important flipside for idling: apart from the above cases
  302. where it is beneficial also for throughput, idling can severely impact
  303. throughput. One important case is random workload. Because of this
  304. issue, BFQ tends to avoid idling as much as possible, when it is not
  305. beneficial also for throughput (as detailed in Section 2). As a
  306. consequence of this behavior, and of further issues described for the
  307. strict_guarantees tunable, short-term service guarantees may be
  308. occasionally violated. And, in some cases, these guarantees may be
  309. more important than guaranteeing maximum throughput. For example, in
  310. video playing/streaming, a very low drop rate may be more important
  311. than maximum throughput. In these cases, consider setting the
  312. strict_guarantees parameter.
  313. slice_idle_us
  314. -------------
  315. Controls the same tuning parameter as slice_idle, but in microseconds.
  316. Either tunable can be used to set idling behavior. Afterwards, the
  317. other tunable will reflect the newly set value in sysfs.
  318. strict_guarantees
  319. -----------------
  320. If this parameter is set (default: unset), then BFQ
  321. - always performs idling when the in-service queue becomes empty;
  322. - forces the device to serve one I/O request at a time, by dispatching a
  323. new request only if there is no outstanding request.
  324. In the presence of differentiated weights or I/O-request sizes, both
  325. the above conditions are needed to guarantee that every BFQ queue
  326. receives its allotted share of the bandwidth. The first condition is
  327. needed for the reasons explained in the description of the slice_idle
  328. tunable. The second condition is needed because all modern storage
  329. devices reorder internally-queued requests, which may trivially break
  330. the service guarantees enforced by the I/O scheduler.
  331. Setting strict_guarantees may evidently affect throughput.
  332. back_seek_max
  333. -------------
  334. This specifies, given in Kbytes, the maximum "distance" for backward seeking.
  335. The distance is the amount of space from the current head location to the
  336. sectors that are backward in terms of distance.
  337. This parameter allows the scheduler to anticipate requests in the "backward"
  338. direction and consider them as being the "next" if they are within this
  339. distance from the current head location.
  340. back_seek_penalty
  341. -----------------
  342. This parameter is used to compute the cost of backward seeking. If the
  343. backward distance of request is just 1/back_seek_penalty from a "front"
  344. request, then the seeking cost of two requests is considered equivalent.
  345. So scheduler will not bias toward one or the other request (otherwise scheduler
  346. will bias toward front request). Default value of back_seek_penalty is 2.
  347. fifo_expire_async
  348. -----------------
  349. This parameter is used to set the timeout of asynchronous requests. Default
  350. value of this is 248ms.
  351. fifo_expire_sync
  352. ----------------
  353. This parameter is used to set the timeout of synchronous requests. Default
  354. value of this is 124ms. In case to favor synchronous requests over asynchronous
  355. one, this value should be decreased relative to fifo_expire_async.
  356. low_latency
  357. -----------
  358. This parameter is used to enable/disable BFQ's low latency mode. By
  359. default, low latency mode is enabled. If enabled, interactive and soft
  360. real-time applications are privileged and experience a lower latency,
  361. as explained in more detail in the description of how BFQ works.
  362. DISABLE this mode if you need full control on bandwidth
  363. distribution. In fact, if it is enabled, then BFQ automatically
  364. increases the bandwidth share of privileged applications, as the main
  365. means to guarantee a lower latency to them.
  366. In addition, as already highlighted at the beginning of this document,
  367. DISABLE this mode if your only goal is to achieve a high throughput.
  368. In fact, privileging the I/O of some application over the rest may
  369. entail a lower throughput. To achieve the highest-possible throughput
  370. on a non-rotational device, setting slice_idle to 0 may be needed too
  371. (at the cost of giving up any strong guarantee on fairness and low
  372. latency).
  373. timeout_sync
  374. ------------
  375. Maximum amount of device time that can be given to a task (queue) once
  376. it has been selected for service. On devices with costly seeks,
  377. increasing this time usually increases maximum throughput. On the
  378. opposite end, increasing this time coarsens the granularity of the
  379. short-term bandwidth and latency guarantees, especially if the
  380. following parameter is set to zero.
  381. max_budget
  382. ----------
  383. Maximum amount of service, measured in sectors, that can be provided
  384. to a BFQ queue once it is set in service (of course within the limits
  385. of the above timeout). According to what said in the description of
  386. the algorithm, larger values increase the throughput in proportion to
  387. the percentage of sequential I/O requests issued. The price of larger
  388. values is that they coarsen the granularity of short-term bandwidth
  389. and latency guarantees.
  390. The default value is 0, which enables auto-tuning: BFQ sets max_budget
  391. to the maximum number of sectors that can be served during
  392. timeout_sync, according to the estimated peak rate.
  393. For specific devices, some users have occasionally reported to have
  394. reached a higher throughput by setting max_budget explicitly, i.e., by
  395. setting max_budget to a higher value than 0. In particular, they have
  396. set max_budget to higher values than those to which BFQ would have set
  397. it with auto-tuning. An alternative way to achieve this goal is to
  398. just increase the value of timeout_sync, leaving max_budget equal to 0.
  399. 4. Group scheduling with BFQ
  400. ============================
  401. BFQ supports both cgroups-v1 and cgroups-v2 io controllers, namely
  402. blkio and io. In particular, BFQ supports weight-based proportional
  403. share. To activate cgroups support, set BFQ_GROUP_IOSCHED.
  404. 4-1 Service guarantees provided
  405. -------------------------------
  406. With BFQ, proportional share means true proportional share of the
  407. device bandwidth, according to group weights. For example, a group
  408. with weight 200 gets twice the bandwidth, and not just twice the time,
  409. of a group with weight 100.
  410. BFQ supports hierarchies (group trees) of any depth. Bandwidth is
  411. distributed among groups and processes in the expected way: for each
  412. group, the children of the group share the whole bandwidth of the
  413. group in proportion to their weights. In particular, this implies
  414. that, for each leaf group, every process of the group receives the
  415. same share of the whole group bandwidth, unless the ioprio of the
  416. process is modified.
  417. The resource-sharing guarantee for a group may partially or totally
  418. switch from bandwidth to time, if providing bandwidth guarantees to
  419. the group lowers the throughput too much. This switch occurs on a
  420. per-process basis: if a process of a leaf group causes throughput loss
  421. if served in such a way to receive its share of the bandwidth, then
  422. BFQ switches back to just time-based proportional share for that
  423. process.
  424. 4-2 Interface
  425. -------------
  426. To get proportional sharing of bandwidth with BFQ for a given device,
  427. BFQ must of course be the active scheduler for that device.
  428. Within each group directory, the names of the files associated with
  429. BFQ-specific cgroup parameters and stats begin with the "bfq."
  430. prefix. So, with cgroups-v1 or cgroups-v2, the full prefix for
  431. BFQ-specific files is "blkio.bfq." or "io.bfq." For example, the group
  432. parameter to set the weight of a group with BFQ is blkio.bfq.weight
  433. or io.bfq.weight.
  434. As for cgroups-v1 (blkio controller), the exact set of stat files
  435. created, and kept up-to-date by bfq, depends on whether
  436. CONFIG_BFQ_CGROUP_DEBUG is set. If it is set, then bfq creates all
  437. the stat files documented in
  438. Documentation/admin-guide/cgroup-v1/blkio-controller.rst. If, instead,
  439. CONFIG_BFQ_CGROUP_DEBUG is not set, then bfq creates only the files::
  440. blkio.bfq.io_service_bytes
  441. blkio.bfq.io_service_bytes_recursive
  442. blkio.bfq.io_serviced
  443. blkio.bfq.io_serviced_recursive
  444. The value of CONFIG_BFQ_CGROUP_DEBUG greatly influences the maximum
  445. throughput sustainable with bfq, because updating the blkio.bfq.*
  446. stats is rather costly, especially for some of the stats enabled by
  447. CONFIG_BFQ_CGROUP_DEBUG.
  448. Parameters to set
  449. -----------------
  450. For each group, there is only the following parameter to set.
  451. weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the
  452. group inside its parent. Available values: 1..1000 (default 100). The
  453. linear mapping between ioprio and weights, described at the beginning
  454. of the tunable section, is still valid, but all weights higher than
  455. IOPRIO_BE_NR*10 are mapped to ioprio 0.
  456. Recall that, if low-latency is set, then BFQ automatically raises the
  457. weight of the queues associated with interactive and soft real-time
  458. applications. Unset this tunable if you need/want to control weights.
  459. [1]
  460. P. Valente, A. Avanzini, "Evolution of the BFQ Storage I/O
  461. Scheduler", Proceedings of the First Workshop on Mobile System
  462. Technologies (MST-2015), May 2015.
  463. http://algogroup.unimore.it/people/paolo/disk_sched/mst-2015.pdf
  464. [2]
  465. P. Valente and M. Andreolini, "Improving Application
  466. Responsiveness with the BFQ Disk I/O Scheduler", Proceedings of
  467. the 5th Annual International Systems and Storage Conference
  468. (SYSTOR '12), June 2012.
  469. Slightly extended version:
  470. http://algogroup.unimore.it/people/paolo/disk_sched/bfq-v1-suite-results.pdf
  471. [3]
  472. https://github.com/Algodev-github/S