All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk, nauman@google.com,
	dpshah@google.com, guijianfeng@cn.fujitsu.com,
	czoccolo@gmail.com
Subject: Re: [PATCH 2/3] cfq-iosched: Implement a tunable group_idle
Date: Wed, 21 Jul 2010 16:13:18 -0400	[thread overview]
Message-ID: <20100721201318.GH20458@redhat.com> (raw)
In-Reply-To: <x49bpa0d3nn.fsf@segfault.boston.devel.redhat.com>

On Wed, Jul 21, 2010 at 03:40:44PM -0400, Jeff Moyer wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > o Implement a new tunable group_idle, which allows idling on the group
> >   instead of a cfq queue. Hence one can set slice_idle = 0 and not idle
> >   on the individual queues but idle on the group. This way on fast storage
> >   we can get fairness between groups at the same time overall throughput
> >   improves.
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > ---
> [snip]
> > @@ -1929,13 +1941,21 @@ static void cfq_arm_slice_timer(struct cfq_data *cfqd)
> >  		return;
> >  	}
> >  
> > +	/* There are other queues in the group, don't do group idle */
> > +	if (group_idle && cfqq->cfqg->nr_cfqq > 1)
> > +		return;
> > +
> >  	cfq_mark_cfqq_wait_request(cfqq);
> >  
> > -	sl = cfqd->cfq_slice_idle;
> > +	if (group_idle)
> > +		sl = cfqd->cfq_group_idle;
> > +	else
> > +		sl = cfqd->cfq_slice_idle;
> 
> What happens when both group_idle and slice_idle are set?

slice_idle prevails. Notice that "group_idle" is a local variable which
is set to 1 only if we decide not to idle on the cfq queue.


>  Is that a
> sane thing to do from a user's perspective?

In fact by default both slice_idle=8 and group_idle=8. Just that in this
mode group_idle never kicks in as slice_idle logic kicks in always before
group_idle logic gets any chance.

> If not, please protect
> against it in the configuration code.  If so, then explain why we prefer
> group_idle here, but slice_idle in completed request for the extend_sl:
> 

In both the places we first prefer slice_idle. Just noticed the value of
"group_idle" in the beginning of arm_time() function and notice in what
circumstances do we set group_idle=1

Thanks
Vivek

> > @@ -3425,7 +3458,10 @@ static void cfq_completed_request(struct request_queue *q, struct request *rq)
> >  		 * the queue.
> >  		 */
> >  		if (cfq_should_wait_busy(cfqd, cfqq)) {
> > -			cfqq->slice_end = jiffies + cfqd->cfq_slice_idle;
> > +			unsigned long extend_sl = cfqd->cfq_slice_idle;
> > +			if (!cfqd->cfq_slice_idle)
> > +				extend_sl = cfqd->cfq_group_idle;
> > +			cfqq->slice_end = jiffies + extend_sl;
> 
> Also, you'll need to add documentation for this new tunable.
> 
> Cheers,
> Jeff

  reply	other threads:[~2010-07-21 20:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 19:06 [RFC PATCH] cfq-iosced: Implement IOPS mode and group_idle tunable V3 Vivek Goyal
2010-07-21 19:06 ` [PATCH 1/3] cfq-iosched: Implment IOPS mode Vivek Goyal
2010-07-21 20:33   ` Jeff Moyer
2010-07-21 20:57     ` Vivek Goyal
2010-07-21 19:06 ` [PATCH 2/3] cfq-iosched: Implement a tunable group_idle Vivek Goyal
2010-07-21 19:40   ` Jeff Moyer
2010-07-21 20:13     ` Vivek Goyal [this message]
2010-07-21 20:54       ` Jeff Moyer
2010-07-21 19:06 ` [PATCH 3/3] cfq-iosched: Print number of sectors dispatched per cfqq slice Vivek Goyal
2010-07-22  5:56 ` [RFC PATCH] cfq-iosced: Implement IOPS mode and group_idle tunable V3 Christoph Hellwig
2010-07-22 14:00   ` Vivek Goyal
2010-07-24  8:51     ` Christoph Hellwig
2010-07-24  9:07       ` Corrado Zoccolo
2010-07-26 14:30         ` Vivek Goyal
2010-07-26 21:21           ` Tuning IO scheduler (Was: Re: [RFC PATCH] cfq-iosced: Implement IOPS mode and group_idle tunable V3) Vivek Goyal
2010-07-26 14:33         ` [RFC PATCH] cfq-iosced: Implement IOPS mode and group_idle tunable V3 Vivek Goyal
2010-07-29 19:57           ` Corrado Zoccolo
2010-07-26 13:51       ` Vivek Goyal
2010-07-22 20:54   ` Vivek Goyal
2010-07-22  7:08 ` Gui Jianfeng
2010-07-22 14:49   ` Vivek Goyal
2010-07-22 23:53     ` Gui Jianfeng
2010-07-26  6:58 ` Gui Jianfeng
2010-07-26 14:10   ` Vivek Goyal
2010-07-27  8:33     ` Gui Jianfeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100721201318.GH20458@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=czoccolo@gmail.com \
    --cc=dpshah@google.com \
    --cc=guijianfeng@cn.fujitsu.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nauman@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.