[12309]BFQ-v3 для .39 и 3.0

Гентушник ?

Именно. А что?

мать моя родная! что ЭТО? diff на >5000 строк! в какой раз они уже его с нуля пишут?

Пришло время переустанавливать Шin... kernel!

Годная вещь =]

>diff на >5000 строк!

они упоролись же.

//Чем оно лучше noop+NCQ?

ядро с нцкью у меня не смогло собрать трерье ядро, вылетали ошибки гцц ))

У тебя хреновое NCQ.

Просто почитай features.

тьфу ты не нцкью, а бфкью вот это самое.

Это ж надо было так опечататься.

В ядро сабж никогда не примут, да?

спермопроблемы

В ядро сабж никогда не примут, да?

Да.

Ну, было бы, кому мейнтейнить. Но зачем?

Стоит пробовать?

The main differences are: - Slices are given in the service domain: tasks are assigned budgets, measured in number of sectors. Once got the disk, a task must however consume its assigned budget within a configurable maximum time (by default, the maximum possible value of the budgets is automaticall computed to comply with this timeout). This allows the desired latency vs «throughput boosting» tradeoff to be set.

- Budgets are scheduled according to a variant of WF2Q+, implemented using an augmented rb-tree to take eligibility into account while preserving an O(log N) overall complexity.

- A low-latency tunable is provided; if enabled, both interactive and soft real-time applications are guaranteed very low latency.

- Latency guarantees are preserved also in presence of NCQ.

- Useful features borrowed from CFQ: cooperating-queues merging (with some additional optimizations with respect to the original CFQ version), static fallback queue for OOM.

- BFQ supports full hierarchical scheduling, exporting a cgroups interface. Each node has a full scheduler, so each group can be assigned its own ioprio and an ioprio_class.

- If the cgroups interface is used, weights can be explictly assigned, otherwise ioprio values are mapped to weights using the relation weight = IOPRIO_BE_NR - ioprio.

- ioprio classes are served in strict priority order, i.e., lower priority queues are not served as long as there are higher priority queues. Among queues in the same class the bandwidth is distributed in proportion to the weights of each queue. A very thin extra bandwidth is however guaranteed to the Idle class, to prevent it from starving.

Regarding what has not changed it is worth noting: - the handling of cfq_io_contexts to associate queues to tasks. Much of the code has been reused just renaming it. (There is room for code sharing with CFQ but we wanted to minimize the impact of this patch.)

- The handling of async queues.

- The handling of idle windows.

- The handling of merging.

- The heuristics to assert that a task is worth an idle window (with minor modifications to hw_tag/CIC_SEEKY detection).