From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler Date: Mon, 02 Jun 2014 11:32:05 -0600 Message-ID: <538CB515.3090700@kernel.dk> References: <20140528221929.GG1419@htj.dyndns.org> <1401354343-5527-1-git-send-email-paolo.valente@unimore.it> <20140530160712.GG24871@htj.dyndns.org> <538926F6.7080409@kernel.dk> <20140531051635.GA19925@mtj.dyndns.org> <538C8A47.1050502@kernel.dk> <20140602172454.GA8912@htj.dyndns.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140602172454.GA8912-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Tejun Heo Cc: Paolo Valente , Li Zefan , Fabio Checconi , Arianna Avanzini , Paolo Valente , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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