All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Fabio Checconi <fchecconi@gmail.com>
Cc: Matthew <jackdachef@gmail.com>,
	Daniel J Blueman <daniel.blueman@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: Fri, 16 May 2008 09:57:15 +0200	[thread overview]
Message-ID: <20080516075715.GX16217@kernel.dk> (raw)
In-Reply-To: <20080516074913.GW16217@kernel.dk>

On Fri, May 16 2008, Jens Axboe wrote:
> On Fri, May 16 2008, Fabio Checconi wrote:
> > > From: Jens Axboe <jens.axboe@oracle.com>
> > > Date: Fri, May 16, 2008 08:40:03AM +0200
> > >
> > ...
> > > I think we can improve this further without getting too involved. If a
> > > 2nd request is seen in cfq_rq_enqueued(), then DO schedule a dispatch
> > > since this likely means that we wont be doing more merges on the first
> > > one.
> > > 
> > 
> > But isn't there the risk that even the second request would be
> > dispatched, while it still could have grown?
> 
> Certainly, you'd only want to dispatch the first request. Ideally we'd
> just get rid of this logic of 'did empty dispatch round' and only
> dispatch requests once merging is done, it's basically the wrong thing
> to do to make it visible to the io scheduler so soon. Well of course
> even more ideally we'd always get big requests submitted, but
> unfortunately many producers aren't that nice.
> 
> The per-process plugging actually solves this nicely, since we do the
> merging outside of the io scheduler. Perhaps just not dispatch on a
> plugged queue would help a bit. I'm somewhat against this principle of
> messing too much with dispatch logic in the schedulers, it'd be nicer to
> solve this higher up.

Something like this...

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 5dfb7b9..5ab1a17 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1775,6 +1775,9 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
 
 	cic->last_request_pos = rq->sector + rq->nr_sectors;
 
+	if (blk_queue_plugged(cfqd->queue))
+		return;
+
 	if (cfqq == cfqd->active_queue) {
 		/*
 		 * if we are waiting for a request for this queue, let it rip
@@ -1784,7 +1787,7 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
 		if (cfq_cfqq_wait_request(cfqq)) {
 			cfq_mark_cfqq_must_dispatch(cfqq);
 			del_timer(&cfqd->idle_slice_timer);
-			blk_start_queueing(cfqd->queue);
+			cfq_schedule_dispatch(cfqd);
 		}
 	} else if (cfq_should_preempt(cfqd, cfqq, rq)) {
 		/*
@@ -1794,7 +1797,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);
+		cfq_schedule_dispatch(cfqd);
 	}
 }
 
@@ -1997,11 +2000,10 @@ static void cfq_kick_queue(struct work_struct *work)
 	struct cfq_data *cfqd =
 		container_of(work, struct cfq_data, unplug_work);
 	struct request_queue *q = cfqd->queue;
-	unsigned long flags;
 
-	spin_lock_irqsave(q->queue_lock, flags);
+	spin_lock_irq(q->queue_lock);
 	blk_start_queueing(q);
-	spin_unlock_irqrestore(q->queue_lock, flags);
+	spin_unlock_irq(q->queue_lock);
 }
 
 /*

-- 
Jens Axboe


  reply	other threads:[~2008-05-16  7:57 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
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 [this message]
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=20080516075715.GX16217@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=daniel.blueman@gmail.com \
    --cc=fchecconi@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 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.