On 06/02/2014 11:42 AM, Tejun Heo wrote: > Hello, Jens. > > On Mon, Jun 02, 2014 at 11:32:05AM -0600, Jens Axboe wrote: >> 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. > > Heh, looks like we're miscommunicating. I don't think anything with > the level of complexity of cfq is realistic for high-iops devices. It > has already become a liability for SATA ssds after all. My suggestion > is that as hierarchical scheduling tends to be logical extension of > flat scheduling, it probably would make sense to implement both > scheduling logics in the same framework as in the cpu scheduler or (to > a lesser extent) cfq. So, a new blk-mq scheduler which can work in > hierarchical mode if blkcg is in active use. But blk-mq will potentially drive anything, so it might not be out of the question with a more expensive scheduling variant, if it makes any sense to do of course. At least until there's no more rotating stuff out there :-). But it's not a priority at all to me yet. As long as we have coexisting IO paths, it'd be trivial to select the needed one based on the device characteristics. > One part I was wondering about is whether we'd need to continue the > modular multiple implementation mechanism. For rotating disks, for > various reasons including some historical ones, we ended up with > multiple ioscheds and somewhat uglily layered blkcg implementations. > Given that the expected characteristics of blk-mq devices are more > consistent, it could be reasonable to stick with single iops and/or > bandwidth scheme. I hope not to do that. I just want something sane and simple (like a deadline scheduler), nothing more. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
