public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: Matthew <jackdachef@gmail.com>,
	Kasper Sandberg <lkml@metanurb.dk>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: performance "regression" in cfq compared to anticipatory, deadline and noop
Date: Wed, 14 May 2008 10:26:23 +0200	[thread overview]
Message-ID: <20080514082622.GA16217@kernel.dk> (raw)
In-Reply-To: <6278d2220805140105x27292033u6a97dcf13ab54263@mail.gmail.com>

On Wed, May 14 2008, Daniel J Blueman wrote:
> >  > > >  > >  > On Sun, 2008-05-11 at 14:14 +0100, Daniel J Blueman wrote:
> >  > > >  > >  > > I've been experiencing this for a while also; an almost 50% regression
> >  > > >  > >  > > is seen for single-process reads (ie sync) if slice_idle is 1ms or
> >  > > >  > >  > > more (eg default of 8) [1], which seems phenomenal.
> >  > > >  > >  > >
> >  > > >  > >  > > Jens, is this the expected price to pay for optimal busy-spindle
> >  > > >  > >  > > scheduling, a design issue, bug or am I missing something totally?
> [snip]
> >  > They seem to start out the same, but then CFQ gets interrupted by a
> >  > timer unplug (which is also odd) and after that the request size drops.
> >  > On most devices you don't notice, but some are fairly picky about
> >  > request sizes. The end result is that CFQ has an average dispatch
> >  > request size of 142kb, where AS is more than double that at 306kb. I'll
> >  > need to analyze the data and look at the code a bit more to see WHY this
> >  > happens.
> >
> >  Here's a test patch, I think we get into this situation due to CFQ being
> >  a bit too eager to start queuing again. Not tested, I'll need to spend
> >  some testing time on this. But I'd appreciate some feedback on whether
> >  this changes the situation! The final patch will be a little more
> >  involved.
> >
> >  diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> >  index b399c62..ebd8ce2 100644
> >  --- a/block/cfq-iosched.c
> >  +++ b/block/cfq-iosched.c
> >  @@ -1775,18 +1775,8 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
> >
> >         cic->last_request_pos = rq->sector + rq->nr_sectors;
> >
> >  -       if (cfqq == cfqd->active_queue) {
> >  -               /*
> >  -                * if we are waiting for a request for this queue, let it rip
> >  -                * immediately and flag that we must not expire this queue
> >  -                * just now
> >  -                */
> >  -               if (cfq_cfqq_wait_request(cfqq)) {
> >  -                       cfq_mark_cfqq_must_dispatch(cfqq);
> >  -                       del_timer(&cfqd->idle_slice_timer);
> >  -                       blk_start_queueing(cfqd->queue);
> >  -               }
> >  -       } else if (cfq_should_preempt(cfqd, cfqq, rq)) {
> >  +       if ((cfqq != cfqd->active_queue) &&
> >  +                  cfq_should_preempt(cfqd, cfqq, rq)) {
> >                 /*
> >                  * not the active queue - expire current slice if it is
> >                  * idle and has expired it's mean thinktime or this new queue
> 
> I find this does address the issue (both with 64KB stride dd and
> hdparm -t; presumably the requests getting merged). Tested on
> 2.6.26-rc2 on Ubuntu HH 804 x86-64, with slice_idle defaulting to 8
> and AHCI on ICH9; disk is ST3320613AS.
> 
> Blktrace profiles from 'dd if=/dev/sda of=/dev/null bs=64k count=1000' are at:
> 
> http://quora.org/blktrace-profiles.tar.bz2

Goodie! I think the below patch is better - we do want to schedule the
queue immediately, but we do not want to interrupt the queuer. So just
kick the workqueue handling of the queue instead of entering the
dispatcher directly. Can you test this one as well? Thanks!

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index f4e1006..e8c1941 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1107,7 +1107,6 @@ static int cfq_dispatch_requests(struct request_queue *q, int force)
 
 		cfq_clear_cfqq_must_dispatch(cfqq);
 		cfq_clear_cfqq_wait_request(cfqq);
-		del_timer(&cfqd->idle_slice_timer);
 
 		dispatched += __cfq_dispatch_requests(cfqd, cfqq, max_dispatch);
 	}
@@ -1769,15 +1768,9 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
 	cic->last_request_pos = rq->sector + rq->nr_sectors;
 
 	if (cfqq == cfqd->active_queue) {
-		/*
-		 * if we are waiting for a request for this queue, let it rip
-		 * immediately and flag that we must not expire this queue
-		 * just now
-		 */
 		if (cfq_cfqq_wait_request(cfqq)) {
-			cfq_mark_cfqq_must_dispatch(cfqq);
 			del_timer(&cfqd->idle_slice_timer);
-			blk_start_queueing(cfqd->queue);
+			kblockd_schedule_work(&cfqd->unplug_work);
 		}
 	} else if (cfq_should_preempt(cfqd, cfqq, rq)) {
 		/*
@@ -1787,7 +1780,7 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
 		 */
 		cfq_preempt_queue(cfqd, cfqq);
 		cfq_mark_cfqq_must_dispatch(cfqq);
-		blk_start_queueing(cfqd->queue);
+		kblockd_schedule_work(&cfqd->unplug_work);
 	}
 }
 

-- 
Jens Axboe


  reply	other threads:[~2008-05-14  8:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-11 13:14 performance "regression" in cfq compared to anticipatory, deadline and noop Daniel J Blueman
2008-05-11 14:02 ` Kasper Sandberg
2008-05-13 12:20   ` Jens Axboe
2008-05-13 12:58     ` Matthew
2008-05-13 13:05       ` Jens Axboe
     [not found]         ` <e85b9d30805130842p3a34305l4ab1e7926e4b0dba@mail.gmail.com>
2008-05-13 18:03           ` Jens Axboe
2008-05-13 18:40             ` Jens Axboe
2008-05-13 19:23               ` Matthew
2008-05-13 19:30                 ` Jens Axboe
2008-05-14  8:05               ` Daniel J Blueman
2008-05-14  8:26                 ` Jens Axboe [this message]
2008-05-14 20:52                   ` Daniel J Blueman
2008-05-14 21:37                     ` Matthew
2008-05-15  7:01                       ` Jens Axboe
2008-05-15 12:21                         ` Fabio Checconi
2008-05-16  6:40                           ` Jens Axboe
2008-05-16  7:46                             ` Fabio Checconi
2008-05-16  7:49                               ` Jens Axboe
2008-05-16  7:57                                 ` Jens Axboe
2008-05-16  8:53                                   ` Daniel J Blueman
2008-05-16  8:57                                     ` Jens Axboe
2008-05-16 15:23                                       ` Matthew
2008-05-16 18:39                                         ` Fabio Checconi
2008-08-24 20:24                           ` Daniel J Blueman
2008-08-25 20:29                             ` Fabio Checconi
2008-08-25 15:39                               ` Daniel J Blueman
2008-08-25 17:06                                 ` Fabio Checconi
2008-12-09 15:14                                   ` Daniel J Blueman
     [not found]                   ` <e85b9d30805140332r3311b2d6r6831d37421ced757@mail.gmail.com>
     [not found]                     ` <e85b9d30805140334q69cb5eacued9a719414e73d53@mail.gmail.com>
     [not found]                       ` <20080514103956.GD16217@kernel.dk>
     [not found]                         ` <e85b9d30805141239g5df9abc6i666b1f621d632b44@mail.gmail.com>
     [not found]                           ` <e85b9d30805161549o7c8f065do24b6567e2ade0afa@mail.gmail.com>
2008-05-19 10:39                             ` Matthew
2008-05-13 13:51     ` Kasper Sandberg
2008-05-14  0:33       ` Kasper Sandberg
  -- strict thread matches above, loose matches on Subject: below --
2008-05-10 19:18 Matthew
     [not found] ` <20080510200053.GA78555@gandalf.sssup.it>
2008-05-10 20:39   ` Matthew
2008-05-10 21:56     ` Fabio Checconi
2008-05-11  0:00     ` Aaron Carroll

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=20080514082622.GA16217@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=daniel.blueman@gmail.com \
    --cc=jackdachef@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@metanurb.dk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox