On 06/02/2014 11:24 AM, Tejun Heo wrote:

Hello, Jens.

On Mon, Jun 02, 2014 at 08:29:27AM -0600, Jens Axboe wrote:

quoted

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.

What I'm planning right now is improving blkcg so that it can do both
proportional and hard limits with high cpu scalability, most likely
using percpu charge caches.  It probably would be best to roll all
those into one piece of logic.  I don't think, well at least hope,
that we'd need multiple modular scheduler / blkcg implementations for
blk-mq and both can be served by built-in scheduling logic.
Regardless of device speed, we'd need some form of fairness
enforcement after all.

For things like blkcg, I agree, it should be able to be common code and
reusable. But there's a need for scheduling beyond that, for people that
don't use control groups (ie most...). And it'd be hard to retrofit cfq
into blk-mq, without rewriting it. I don't believe we need anything this
fancy for blk-mq, hopefully. At least having simple deadline scheduling
would be Good Enough for the foreseeable future.

-- 
Jens Axboe