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

Fabio Checconi fchecconi at gmail.com
Wed Nov 19 02:17:01 PST 2008


> From: Aaron Carroll <aaronc at gelato.unsw.edu.au>
> Date: Wed, Nov 19, 2008 12:52:42PM +1100
>
> Fabio Checconi wrote:
> >   - To detect hw tagging in BFQ we consider a sample valid iff the
> >     number of requests that the scheduler could have dispatched (given
> >     by cfqd->rb_queued + cfqd->rq_in_driver, i.e., the ones still into
> >     the scheduler plus the ones into the driver) is higher than the
> >     CFQ_HW_QUEUE_MIN threshold.  This obviously caused no problems
> >     during testing, but the way CFQ uses now seems a little bit
> >     strange.
> 
> BFQ's tag detection logic is broken in the same way that CFQ's used to
> be.  Explanation is in this patch:
> 

If you look at bfq_update_hw_tag(), the logic introduced by the patch
you mention is still there; BFQ starts with ->hw_tag = 1, and updates it
every 32 valid samples.  What changed WRT your patch, apart from the
number of samples, is that the condition for a sample to be valid is:

  bfqd->rq_in_driver + bfqd->queued >= 5

while in your patch it is:

  cfqd->rq_queued > 5 || cfqd->rq_in_driver > 5

We preferred the first one because that sum better reflects the number
of requests that could have been dispatched, and I don't think that this
is wrong.

There is a problem, but it's not within the tag detection logic itself.


More information about the Containers mailing list