{"push_id":549336571,"size":1,"distinct_size":1,"ref":"refs/heads/nightlies","head":"d74978f3388c67e95250b64424547e1d8ee7c4ba","before":"c3e88e25cce287b436db013acb98afe822af346a","commits":[{"sha":"d74978f3388c67e95250b64424547e1d8ee7c4ba","author":{"email":"20b1b82ea87150022f6495522a9f5e355ea8b305@gmail.com","name":"Arianna Avanzini"},"message":"block: introduce the BFQ-v6 I/O sched for 3.4\n\nAdd the BFQ-v6 I/O scheduler to 3.4.\nThe general structure is borrowed from CFQ, as much code. A (bfq_)queue is\nassociated to each task doing I/O on a device, and each time a scheduling\ndecision has to be made a queue is selected and served until it expires.\n\n    - Slices are given in the service domain: tasks are assigned budgets,\n      measured in number of sectors. Once got the disk, a task must\n      however consume its assigned budget within a configurable maximum time\n      (by default, the maximum possible value of the budgets is automatically\n      computed to comply with this timeout). This allows the desired latency\n      vs \"throughput boosting\" tradeoff to be set.\n\n    - Budgets are scheduled according to a variant of WF2Q+, implemented\n      using an augmented rb-tree to take eligibility into account while\n      preserving an O(log N) overall complexity.\n\n    - A low-latency tunable is provided; if enabled, both interactive and soft\n      real-time applications are guaranteed very low latency.\n\n    - Latency guarantees are preserved also in presence of NCQ.\n\n    - Also with flash-based devices, a high throughput is achieved while\n      still preserving latency guarantees.\n\n    - A useful feature borrowed from CFQ: static fallback queue for OOM.\n\n    - Differently from CFQ, BFQ uses a unified mechanism (Early Queue Merge,\n      EQM) to get a sequential read pattern, and hence a high throughput,\n      with any set of processes performing interleaved I/O. EQM also\n      preserves low latency. The code for detecting whether two queues have\n      to be merged is a slightly modified version of the CFQ code for\n      detecting whether two queues belong to cooperating processes and whether\n      the service of a queue should be preempted to boost the throughput.\n\n    - BFQ supports full hierarchical scheduling, exporting a cgroups\n      interface.  Each node has a full scheduler, so each group can\n      be assigned its own ioprio (mapped to a weight, see next point)\n      and an ioprio_class.\n\n    - If the cgroups interface is used, weights can be explictly assigned,\n      otherwise ioprio values are mapped to weights using the relation\n      weight = IOPRIO_BE_NR - ioprio.\n\n    - ioprio classes are served in strict priority order, i.e., lower\n      priority queues are not served as long as there are higher priority\n      queues.  Among queues in the same class the bandwidth is distributed\n      in proportion to the weight of each queue. A very thin extra bandwidth\n      is however guaranteed to the Idle class, to prevent it from starving.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>","distinct":true,"url":"https://api.github.com/repos/GuneetAtwal/kernel_h1s/commits/d74978f3388c67e95250b64424547e1d8ee7c4ba"}]}