From: Jens Axboe <jaxboe@fusionio.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chris Mason <chris.mason@oracle.com>,
Linux/m68k <linux-m68k@vger.kernel.org>
Subject: Re: [GIT PULL] Core block IO bits for 2.6.39
Date: Sat, 26 Mar 2011 19:48:32 +0100 [thread overview]
Message-ID: <4D8E3500.6090208@fusionio.com> (raw)
In-Reply-To: <4D8E1A1A.8010300@fusionio.com>
On 2011-03-26 17:53, Jens Axboe wrote:
> On 2011-03-26 17:48, Linus Torvalds wrote:
>> On Fri, Mar 25, 2011 at 11:29 PM, Jens Axboe <jaxboe@fusionio.com> wrote:
>>> +
>>> + /* Use 3ms as that was the old plug delay */
>>> + blk_delay_queue(q, msecs_to_jiffies(3));
>>
>> That's bogus. blk_delay_queue() already takes msecs, not jiffies.
>
> You are right, braino.
>
>> Also, do we really need to delay every unplug like this? It seems sad.
>> A 3ms delay is a long time these days - admittedly most people
>> hopefully use ATA these days if they have an SSD or something, but
>> still..
>
> Depends on whether you want the 'call me back, I ran into busy this
> time' or the 'recall me immediately'.
>
> I'll take a look at the IDE case tonight and submit a real fix.
It's not completely clear cut what the delays should be in the various
old replug cases. Only for the drive sleeping can I make an educated
guess since we now the timeout period.
So something like this. Retains the same recall delay as we had before.
Someone who cares is free to go and optimize this, if the queue rerun
delay should be shorter in some cases.
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index f407784..0e406d73 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -440,6 +440,7 @@ void do_ide_request(struct request_queue *q)
struct ide_host *host = hwif->host;
struct request *rq = NULL;
ide_startstop_t startstop;
+ unsigned long queue_run_ms = 3; /* old plug delay */
spin_unlock_irq(q->queue_lock);
@@ -459,6 +460,9 @@ repeat:
prev_port = hwif->host->cur_port;
if (drive->dev_flags & IDE_DFLAG_SLEEPING &&
time_after(drive->sleep, jiffies)) {
+ unsigned long left = jiffies - drive->sleep;
+
+ queue_run_ms = jiffies_to_msecs(left + 1);
ide_unlock_port(hwif);
goto plug_device;
}
@@ -547,8 +551,10 @@ plug_device:
plug_device_2:
spin_lock_irq(q->queue_lock);
- if (rq)
+ if (rq) {
blk_requeue_request(q, rq);
+ blk_delay_queue(q, queue_run_ms);
+ }
}
void ide_requeue_and_plug(ide_drive_t *drive, struct request *rq)
@@ -562,6 +568,10 @@ void ide_requeue_and_plug(ide_drive_t *drive, struct request *rq)
blk_requeue_request(q, rq);
spin_unlock_irqrestore(q->queue_lock, flags);
+
+ /* Use 3ms as that was the old plug delay */
+ if (rq)
+ blk_delay_queue(q, 3);
}
static int drive_is_ready(ide_drive_t *drive)
--
Jens Axboe
next prev parent reply other threads:[~2011-03-26 18:48 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 13:43 [GIT PULL] Core block IO bits for 2.6.39 Jens Axboe
2011-03-24 18:30 ` [GIT PULL] Core block IO bits for 2.6.39 - early Oops Markus Trippelsdorf
2011-03-24 18:36 ` Jens Axboe
2011-03-24 18:47 ` Markus Trippelsdorf
2011-03-24 18:51 ` Jens Axboe
2011-03-24 18:54 ` Markus Trippelsdorf
2011-03-24 18:58 ` Jens Axboe
2011-03-24 19:34 ` Markus Trippelsdorf
2011-03-24 19:36 ` Jens Axboe
2011-03-24 19:45 ` Markus Trippelsdorf
2011-03-24 19:57 ` Jens Axboe
2011-03-24 20:06 ` Markus Trippelsdorf
2011-03-24 21:01 ` Jens Axboe
2011-03-24 21:41 ` Markus Trippelsdorf
2011-03-25 7:23 ` Jens Axboe
2011-03-25 8:37 ` Markus Trippelsdorf
2011-03-25 8:44 ` Jens Axboe
2011-03-25 9:27 ` Markus Trippelsdorf
2011-03-25 9:57 ` Markus Trippelsdorf
2011-03-25 10:11 ` Jens Axboe
2011-03-25 12:44 ` Jens Axboe
2011-03-25 13:09 ` Markus Trippelsdorf
2011-03-25 14:10 ` Jens Axboe
2011-03-25 14:14 ` Markus Trippelsdorf
2011-03-25 14:18 ` Chris Mason
2011-03-25 14:19 ` Chris Mason
2011-03-25 14:24 ` Markus Trippelsdorf
2011-03-25 14:20 ` Jens Axboe
2011-03-25 14:28 ` Markus Trippelsdorf
2011-03-25 15:51 ` Jens Axboe
2011-03-25 15:58 ` Markus Trippelsdorf
2011-03-25 16:01 ` Jens Axboe
2011-03-24 22:06 ` Markus Trippelsdorf
2011-03-25 4:41 ` Dave Chinner
2011-03-25 7:26 ` Jens Axboe
2011-03-25 11:59 ` Theodore Tso
2011-03-25 12:14 ` Jens Axboe
2011-03-25 12:33 ` Ted Ts'o
2011-03-25 12:43 ` Jens Axboe
2011-03-25 13:01 ` Chris Mason
2011-03-25 21:35 ` [GIT PULL] Core block IO bits for 2.6.39 Geert Uytterhoeven
2011-03-26 6:29 ` Jens Axboe
2011-03-26 7:21 ` Geert Uytterhoeven
2011-03-26 8:25 ` Jens Axboe
2011-03-26 8:34 ` Geert Uytterhoeven
2011-03-26 9:26 ` Jens Axboe
2011-03-26 16:48 ` Linus Torvalds
2011-03-26 16:53 ` Jens Axboe
2011-03-26 18:48 ` Jens Axboe [this message]
2011-03-27 13:21 ` Alan Cox
2011-03-27 11:49 ` Avi Kivity
2011-03-27 12:00 ` Jens Axboe
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=4D8E3500.6090208@fusionio.com \
--to=jaxboe@fusionio.com \
--cc=chris.mason@oracle.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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