Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

From: Jens Axboe
Date: Fri May 30 2014 - 20:49:04 EST


On 2014-05-30 10:07, Tejun Heo wrote:
We do have multiple ioscheds but sans for anticipatory which pretty
much has been superceded by cfq, they serve different purposes and I'd
really hate the idea of carrying two mostly similar ioscheds in tree.

AS was removed, and exactly for that reason. So lets make one thing very clear: we are not going to carry two implementations of CFQ, that differ in various ways. That will not happen. We're going to end up with one "smart" IO scheduler, not several of them.

For some reason, blkcg implementation seems completely different but
outside of that, bfq doesn't really seem to have diverged a lot from
cfq and the most likely and probably only way for it to be merged
would be if you just mutate cfq into bfq. The whole effort is mostly
about characterizing and refining the scheduling algorithm anyway,
right? I'd really love to see that happening.

Patching CFQ would be the right way to go, imho. That would also make it very clear what the steps are to get there, leaving us with something that can actually be backtracked and debugged. I think the patch series already looks pretty good, basically patch #2 "just" needs to be turned into a series of patches for CFQ.

What I really like about the implementation is, as Tejun highlights, that the algorithm is detailed and characterized. Nobody ever wrote any detailed documentation on CFQ - I think the closest is a talk I gave at LCA in 2007 or so. That said, the devil is _always_ in the details when it comes to nice algorithms. When theory meets practice, then the little tweaks and tunings required to not drop 10% there or 20% here is when it gets ugly. And that's where CFQ has the history going for it, at least. Which is another reason for turning patch #2 into a series of changes for CFQ instead. We need to end up with something where we can potentially bisect our way down to whatever caused any given regression. The worst possible situation is "CFQ works fine for this workload, but BFQ does not" or vice versa. Or hangs, or whatever it might be.


--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/