lkml.org 
[lkml]   [2014]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler
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



\
 
 \ /
  Last update: 2014-05-31 03:21    [W:0.329 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site