All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	Linux-Kernel <linux-kernel@vger.kernel.org>,
	Jeff Moyer <jmoyer@redhat.com>, Shaohua Li <shaohua.li@intel.com>,
	Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Subject: Re: [PATCH 2/2] cfq-iosched: RQ_NOIDLE enabled for SYNC_WORKLOAD
Date: Wed, 7 Jul 2010 11:52:00 -0400	[thread overview]
Message-ID: <20100707155200.GH2474@redhat.com> (raw)
In-Reply-To: <20100707154631.GG2474@redhat.com>

On Wed, Jul 07, 2010 at 11:46:31AM -0400, Vivek Goyal wrote:
> On Wed, Jul 07, 2010 at 05:23:47PM +0200, Corrado Zoccolo wrote:
> > RQ_NOIDLE flag is meaningful and should be honored for SYNC_WORKLOAD,
> > without further checks.
> > RQ_NOIDLE can be used to mark the last request of a sequence for which
> > - we want to idle between the requests of the sequence, to keep locality
> > - we don't want to idle after the sequence, because we know that no new
> >   nearby requests will follow, so we should switch servicing other
> >   queues.
> 
> Corrado, in higher layers any WRITE_SYNC request currently is marked
> as RQ_NOIDLE. At that point it is just not known whether there will be
> another request after this or not. So I would not think of RQ_NOIDLE
> as being conclusively telling us that this is last request in the
> sequence.
> 
> I think requst being WRITE_SYNC, we just don't know if the application
> is going to write more or not immediately. fsync, O_SYNC etc fall in
> this category.
> 
> But in general I like the idea of getting rid of idling on as many cases
> as possiblle. Jeff's recent posting to fix fsync issue depends on idling
> even on WRITE_SYNC queues so your patch and his patchsets are
> fundamentally incompatible.
> 
> Whether to idle on WRITE_SYNC or not, I will leave it to Jens (I just
> don't know the answer to that question. :-)). But in general I want to
> get rid of idling as much as possible otherwise it becomes a serious
> bottleneck in any kind of performance testing on higher end storage.
> 
> At the same time not idling runs the risk of process doing WRITE_SYNC
> not getting fair share in presence of sequential readers if writer does
> not keep the queue busy.
> 
> I will do some testing with this patchset little later.

Hmm..., noticed that you are still using Jens's old mail id. Fixing it.

Thanks
Vivek
> 
> > This patch fixes this behaviour, making it similar to how it behaved
> > before 8e55063, but still fixing the corner cases that were the
> > motivation for it.
> > 
> > Signed-off-by: Corrado Zoccolo <czoccolo@gmail.com>
> > ---
> >  block/cfq-iosched.c |   15 ++++++++++-----
> >  1 files changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> > index 5ef9a5d..cac3afb 100644
> > --- a/block/cfq-iosched.c
> > +++ b/block/cfq-iosched.c
> > @@ -3356,12 +3356,17 @@ static void cfq_completed_request(struct request_queue *q, struct request *rq)
> >  				cfqd->noidle_tree_requires_idle |= bitmask;
> >  
> >  			/*
> > -			 * Idling is enabled for SYNC_WORKLOAD.
> > -			 * SYNC_NOIDLE_WORKLOAD idles at the end of the tree
> > -			 * only if we processed at least one !rq_noidle request
> > +			 * Idling is enabled for:
> > +			 * - the last sync queue of a group
> > +			 * - SYNC_WORKLOAD queues, for !rq_noidle requests
> > +			 * - SYNC_NOIDLE_WORKLOAD "at the end of the tree"
> > +			 *   if at least one queue sent !rq_noidle requests
> > +			 *   not followed by at least one rq_noidle request.
> >  			 */
> > -			if (cfqd->serving_type == SYNC_WORKLOAD
> > -			    || cfqd->noidle_tree_requires_idle
> > +			if ((cfqd->serving_type == SYNC_WORKLOAD
> > +			     && !rq_noidle(rq))
> > +			    || (cfqd->serving_type == SYNC_NOIDLE_WORKLOAD
> > +				&& cfqd->noidle_tree_requires_idle)
> >  			    || cfqq->cfqg->nr_cfqq == 1)
> >  				cfq_arm_slice_timer(cfqd);
> >  		}
> > -- 
> > 1.6.4.4

  reply	other threads:[~2010-07-07 15:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 15:23 [PATCH 1/2] cfq-iosched: fix tree-wide handling of rq_noidle Corrado Zoccolo
2010-07-07 15:23 ` [PATCH 2/2] cfq-iosched: RQ_NOIDLE enabled for SYNC_WORKLOAD Corrado Zoccolo
2010-07-07 15:46   ` Vivek Goyal
2010-07-07 15:52     ` Vivek Goyal [this message]
2010-07-07 16:04     ` Corrado Zoccolo
2010-07-07 16:13     ` Christoph Hellwig
2010-07-07 17:12       ` Vivek Goyal
  -- strict thread matches above, loose matches on Subject: below --
2010-07-07 15:55 [PATCH 1/2] cfq-iosched: fix tree-wide handling of rq_noidle Corrado Zoccolo
2010-07-07 15:55 ` [PATCH 2/2] cfq-iosched: RQ_NOIDLE enabled for SYNC_WORKLOAD Corrado Zoccolo

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=20100707155200.GH2474@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=czoccolo@gmail.com \
    --cc=guijianfeng@cn.fujitsu.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.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.