Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler
From: Jens Axboe
Date: Mon Jun 02 2014 - 10:29:36 EST
On 2014-05-30 23:16, Tejun Heo wrote:
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
--
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/