[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