Re: [patch 0/4] [RFC] Another proportional weight IO controller

[Fabio Checconi <fchecconi@gmail.com>]

> From: Nauman Rafique <nauman@google.com>
> Date: Thu, Nov 13, 2008 02:27:41PM -0800
>
> On Thu, Nov 13, 2008 at 11:15 AM, Fabio Checconi <fchecconi@gmail.com> wrote:
> >> How the proportional weight division is done among tasks is a property
> >> of IO scheduler. cfq decides to use time slices according to priority
> >> and bfq decides to use tokens. So probably we can't move this to common
> >> elevator layer.
> >>
> >
> > cfq and bfq are pretty similar in the concepts they adopt, and the pure
> > time-based approach of cfq can be extended to arbitrary hierarchies.
> >
> > Even in bfq, when dealing with groups that generate only seeky traffic
> > we don't try to be fair in the service domain, as it would decrease too
> > much the aggregate throughput, but we fall back to a time-based approach.
> >
> > [ This is a design choice, but it does not depend on the algorithms,
> >  and of course can be changed... ]
> >
> > The two approaches can be mixed/unified, for example, using wf2q+ to
> > schedule the slices, in the time domain, of cfq; the main remaining
> > difference would be the ability of bfq to provide service-domain
> > guarantees.
> 
> Before going into the design of elevator level scheduler, we should
> have some consensus on abandoning the two level approach. Infact, it
> would be useful if we had Ryo and Satoshi jump into this discussion
> and express their opinion.
> 

You're right.  I was only trying to give some design elements thinking
that they could help in the evaluation of the two approaches, talking
of the one I know better.


...
> >> So at this point of time I think that probably porting BFQ's hierarchical
> >> scheduling implementation to other IO schedulers might make sense. Thoughts?
> >>
> >
> > IMO for cfq, given the similarities, this can be done without conceptual
> > problems.  How to do that for schedulers like as, noop or deadline, and
> > if this is the best solution, is an interesting problem :)
> 
> It might be a little too early to start patching things into other
> schedulers. First, because we still don't have a common ground on the
> exact approach for proportional bandwidth division. Second, if
> somebody is using vanilla no-op, deadline or as, do they really care
> about proportional division? If they did, they would probably be using
> cfq already. So we can have something going for cfq first, and then we
> can move to other schedulers.
> 

Sorry for being unclear, I didn't want to start patching anything.  In my
opinion a hierarchical extension of as/deadline poses some interesting
scheduling issues, and exploring them can help in making better decisions.