BFQ I/O Scheduler Lands Along With New Kyber Scheduler

[sarfarazahmad]

Michael plan on testing this? Blk-mq +BFQ vs mainline CFQ sounds interesting. Differences might not be that evident until we scale up IOPS to a very high degree

[Vistaus]

They're both mq schedulers, before BFQ was to land mq did not support having schedulers, and BFQ was made for the previous system, so work was needed before it could land. Now that this work is done it's easier for others.

Yeah right. I'm willing to bet it's because Kyber was developed by Facebook. Big companies often see their work get implemented faster than work by individuals.

[davidbepo]

i have a problem Michael.
i tried to make a cooment on this thread and it gave a JSON error and now my network can't access phoronix
i am writing this from other network, my user works fine

[caligula]

Yeah right. I'm willing to bet it's because Kyber was developed by Facebook. Big companies often see their work get implemented faster than work by individuals.

It's ok as long as they don't force the crappy D language on kernel developers.

[PuckPoltergeist]

The former is not from a big company and the latter is. Whether people like it or not, if you're working for a big company you're likely to be treated differently.

As Linus is trusting people and not companies, this is very unlikely.

[geearf]

Yeah right. I'm willing to bet it's because Kyber was developed by Facebook. Big companies often see their work get implemented faster than work by individuals.

You're right, that's why AMD was able to get DAL through the first time

[starshipeleven]

For those wondering WTF is Kyber, read here from the patch https://patchwork.kernel.org/patch/9680757/

The Kyber I/O scheduler is an I/O scheduler for fast devices designed to
scale to multiple queues. Users configure only two knobs, the target
read and synchronous write latencies, and the scheduler tunes itself to
achieve that latency goal.

The implementation is based on "tokens", built on top of the scalable
bitmap library. Tokens serve as a mechanism for limiting requests. There
are two tiers of tokens: queueing tokens and dispatch tokens.

A queueing token is required to allocate a request. In fact, these
tokens are actually the blk-mq internal scheduler tags, but the
scheduler manages the allocation directly in order to implement its
policy.

Dispatch tokens are device-wide and split up into two scheduling
domains: reads vs. writes. Each hardware queue dispatches batches
round-robin between the scheduling domains as long as tokens are
available for that domain.

These tokens can be used as the mechanism to enable various policies.
The policy Kyber uses is inspired by active queue management techniques
for network routing, similar to blk-wbt. The scheduler monitors
latencies and scales the number of dispatch tokens accordingly. Queueing
tokens are used to prevent starvation of synchronous requests by
asynchronous requests.

Various extensions are possible, including better heuristics and ionice
support. The new scheduler isn't set as the default yet.

[pal666]

Big companies often see their work get implemented faster than work by individuals.

big companies often pay fulltime devs for implementing work faster

[EricBlair]

big companies often pay fulltime devs for implementing work faster

True, also big companies can meet the questions "Is anybody actually using it?" and "Who will maintain it once it is merged?"

[Vistaus]

You're right, that's why AMD was able to get DAL through the first time

That's why I said "often", rather than "always". Because there are always exceptions.