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: >> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
