[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081118194701.GC4283@redhat.com>
Date: Tue, 18 Nov 2008 14:47:01 -0500
From: Vivek Goyal <vgoyal@...hat.com>
To: Jens Axboe <jens.axboe@...cle.com>
Cc: Fabio Checconi <fchecconi@...il.com>,
Nauman Rafique <nauman@...gle.com>,
Li Zefan <lizf@...fujitsu.com>,
Divyesh Shah <dpshah@...gle.com>,
Ryo Tsuruta <ryov@...inux.co.jp>, linux-kernel@...r.kernel.org,
containers@...ts.linux-foundation.org,
virtualization@...ts.linux-foundation.org, taka@...inux.co.jp,
righi.andrea@...il.com, s-uchida@...jp.nec.com,
fernando@....ntt.co.jp, balbir@...ux.vnet.ibm.com,
akpm@...ux-foundation.org, menage@...gle.com, ngupta@...gle.com,
riel@...hat.com, jmoyer@...hat.com, peterz@...radead.org,
paolo.valente@...more.it
Subject: Re: [patch 0/4] [RFC] Another proportional weight IO controller
On Tue, Nov 18, 2008 at 08:12:08PM +0100, Jens Axboe wrote:
> On Tue, Nov 18 2008, Fabio Checconi wrote:
> > > From: Vivek Goyal <vgoyal@...hat.com>
> > > Date: Tue, Nov 18, 2008 09:07:51AM -0500
> > >
> > > On Tue, Nov 18, 2008 at 01:05:08PM +0100, Fabio Checconi wrote:
> > ...
> > > > I have to think a little bit on how it would be possible to support
> > > > an option for time-only budgets, coexisting with the current behavior,
> > > > but I think it can be done.
> > > >
> > >
> > > IIUC, bfq and cfq are different in following manner.
> > >
> > > a. BFQ employs WF2Q+ for fairness and CFQ employes weighted round robin.
> > > b. BFQ uses the budget (sector count) as notion of service and CFQ uses
> > > time slices.
> > > c. BFQ supports hierarchical fair queuing and CFQ does not.
> > >
> > > We are looking forward for implementation of point C. Fabio seems to
> > > thinking of supporting time slice as a service (B). It seems like
> > > convergence of CFQ and BFQ except the point A (WF2Q+ vs weighted round
> > > robin).
> > >
> > > It looks like WF2Q+ provides tighter service bound and bfq guys mention
> > > that they have been able to ensure throughput while ensuring tighter
> > > bounds. If that's the case, does that mean BFQ is a replacement for CFQ
> > > down the line?
> > >
> >
> > BFQ started from CFQ, extending it in the way you correctly describe,
> > so it is indeed very similar. There are also some minor changes to
> > locking, cic handling, hw_tag detection and to the CIC_SEEKY heuristic.
> >
> > The two schedulers share similar goals, and in my opinion BFQ can be
> > considered, in the long term, a CFQ replacement; *but* before talking
> > about replacing CFQ we have to consider that:
> >
> > - it *needs* review and testing; we've done our best, but for sure
> > it's not enough; review and testing are never enough;
> > - the service domain fairness, which was one of our objectives, requires
> > some extra complexity; the mechanisms we used and the design choices
> > we've made may not fit all the needs, or may not be as generic as the
> > simpler CFQ's ones;
> > - CFQ has years of history behind and has been tuned for a wider
> > variety of environments than the ones we've been able to test.
> >
> > If time-based fairness is considered more robust and the loss of
> > service-domain fairness is not a problem, then the two schedulers can
> > be made even more similar.
>
> My preferred approach here would be, in order or TODO:
>
> - Create and test the smallish patches for seekiness, hw_tag checking,
> and so on for CFQ.
> - Create and test a WF2Q+ service dispatching patch for CFQ.
>
Hi Jens,
What do you think about "hierarchical" and cgroup part of BFQ patch? Do
you intend to incorporate/include that piece also or do you think that's
not the way to go for IO controller stuff.
Thanks
Vivek
> and if there are leftovers after that, we could even conditionally
> enable some of those if appropriate. I think the WF2Q+ is quite cool and
> could be easily usable as the default, so it's definitely a viable
> alternative.
>
> My main goal here is basically avoiding addition of Yet Another IO
> scheduler, especially one that is so closely tied to CFQ already.
>
> I'll start things off by splitting cfq into a few files similar to what
> bfq has done, as I think it makes a lot of sense. Fabio, if you could
> create patches for the small behavioural changes you made, we can
> discuss and hopefully merge those next.
>
> --
> Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists