On 2014-05-30 23:16, Tejun Heo wrote:

quoted

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.

It's likely that there will be some workloads out there which may be
affected adversely, which is true for any change really but with both
the core scheduling and heuristics properly characterized at least
finding a reasonable trade-off should be much less of a crapshoot and
the expected benefits seem to easily outweigh the risks as long as we
can properly sequence the changes.

Exactly, I think we are pretty much on the same page here. As I said in 
the previous email, the biggest thing I care about is not adding a new 
IO scheduler wholesale. If Paolo can turn the "add BFQ" patch into a 
series of patches against CFQ, then I would have no issue merging it for 
testing (and inclusion, when it's stable enough).

One thing I've neglected to bring up but have been thinking about - 
we're quickly getting to the point where the old request_fn IO path will 
become a legacy thing, mostly in maintenance mode. That isn't a problem 
for morphing bfq and cfq, but it does mean that development efforts in 
this area would be a lot better spent writing an IO scheduler that fits 
into the blk-mq framework instead.

I realize this is a tall order right now, as I haven't included any sort 
of framework for that in blk-mq yet. So what I envision happening is 
that I will write a basic deadline (ish) scheduler for blk-mq, and 
hopefully others can then pitch in and we can get the ball rolling on 
that side as well.

-- 
Jens Axboe