lkml.org 
[lkml]   [2010]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2010-01-13 12:21    [W:0.080 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site