Messages in this thread | | | Date | Wed, 13 Jan 2010 06:18:07 -0500 | From | Vivek Goyal <> | Subject | Re: [RFC]cfq-iosched: quantum check tweak |
| |
On Wed, Jan 13, 2010 at 04:17:35PM +0800, Shaohua Li wrote: [..] > > > static bool cfq_may_dispatch(struct cfq_data *cfqd, struct cfq_queue *cfqq) > > > { > > > unsigned int max_dispatch; > > > @@ -2258,7 +2273,10 @@ static bool cfq_may_dispatch(struct cfq_ > > > if (cfqd->sync_flight && !cfq_cfqq_sync(cfqq)) > > > return false; > > > > > > - max_dispatch = cfqd->cfq_quantum; > > > + max_dispatch = cfqd->cfq_quantum / 2; > > > + if (max_dispatch < CFQ_SOFT_QUANTUM) > > > > We don't have to hardcode CFQ_SOFT_QUANTUM or in fact we don't need it. We can > > derive the soft limit from hard limit (cfq_quantum). Say soft limit will be > > 50% of cfq_quantum value. > I'm hoping this doesn't give user a surprise. Say cfq_quantum sets to 7, then we > start doing throttling from 3 requests. Adding the CFQ_SOFT_QUANTUM gives a compatibility > against old behavior at least. Am I over thinking? >
I would not worry too much about that. If you are really worried about that, then create one Documentation/block/cfq-iosched.txt and document how cfq_quantum works so that users know that cfq_quantum is upper hard limit and internal soft limit is cfq_quantum/2.
Thanks Vivek
> > > + max_dispatch = min_t(unsigned int, CFQ_SOFT_QUANTUM, > > > + cfqd->cfq_quantum); > > > if (cfq_class_idle(cfqq)) > > > max_dispatch = 1; > > > > > > @@ -2275,7 +2293,7 @@ static bool cfq_may_dispatch(struct cfq_ > > > /* > > > * We have other queues, don't allow more IO from this one > > > */ > > > - if (cfqd->busy_queues > 1) > > > + if (cfqd->busy_queues > 1 && cfq_slice_used_soon(cfqd, cfqq)) > > > return false; > > > > So I guess here we can write something as follows. > > > > if (cfqd->busy_queues > 1 && cfq_slice_used_soon(cfqd, cfqq)) > > return false; > > > > if (cfqd->busy_queues == 1) > > max_dispatch = -1; > > else > > /* > > * Normally we start throttling cfqq when cfq_quantum/2 > > * requests have been dispatched. But we can drive > > * deeper queue depths at the beginning of slice > > * subjected to upper limit of cfq_quantum. > > */ > > max_dispatch = cfqd->cfq_quantum; > ok. > > Thanks, > Shaohua
| |