From: "Indan Zupancic" <indan@nul.nu>
To: "Tejun Heo" <htejun@gmail.com>
Cc: "Paul Mundt" <lethal@linux-sh.org>,
jeff@garzik.org, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, garyhade@us.ibm.com
Subject: Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Date: Sun, 20 May 2007 21:47:33 +0200 (CEST) [thread overview]
Message-ID: <3378.81.207.0.53.1179690453.squirrel@secure.samage.net> (raw)
In-Reply-To: <465082BF.2070306@gmail.com>
On Sun, May 20, 2007 19:17, Tejun Heo wrote:
> Indan Zupancic wrote:
>> So over all it takes half a second longer to detect the disk, but
>> because everything waits on it, it takes more than three seconds
>> longer to resume.
>
> Eeeek. Extra three secs doesn't sound too hot. :-(
Hey, without your reset fix it was 11 seconds slower. ;-)
Well, it used to be around 1.7 seconds to resume, and now (after the fixes)
it's 2.8 (according to the dmesg timestamps). But the first timestamp printed
was 0.7, and now it's 2.1, so I don't know if it's a real slowdown or that the timer
is set correctly earlier. That was with 2.19 btw, I don't know what happened in
the meantime. I suspect the timer changes. To know for sure I'd need to boot
an older kernel and measure resume time with a stopwatch.
>> Setting manage_start_stop to 0 fixes it and is good enough for me, I
>> didn't notice anything bad yet because of the unmanaged
>> stop. Implementing background spin up will fix it too.
>
> Just commenting out sd_resume() would be a better solution for your
> case tho.
I like your idea below more. ;-)
>>>> Everything seems to work fine without sd_resume(), so why is it needed?
>>> Because not all disks spin up without being told to do so and like it or
>>> not spinning disks up on resume is the default behavior. As I wrote in
>>> the other reply, it would be worthwhile to make it configurable.
>>
>> Not even after they receive a read command? Ugh.
>
> After receiving a command which requires media access, they do. What
> I was saying is that the current default behavior is to spin up all
> devices on resume and part of that is achieved by sd_resume().
>
> Hmmm... skipping START_STOP during sd_resume() actually is a pretty
> good solution for ATA devices. I'll think about it.
I can't speak for others, but for me this would fix all regressions and even
disk spin up seems half a second faster without the START_STOP.
It would also solve the laptopmode thing, not unnecessarily spinning up
disks that don't need to be (if the hardware doesn't do it).
Greetings,
Indan
next prev parent reply other threads:[~2007-05-20 19:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-10 7:20 libata reset-seq merge broke sata_sil on sh Paul Mundt
2007-05-10 11:28 ` Tejun Heo
2007-05-10 11:53 ` Tejun Heo
2007-05-10 12:46 ` Paul Mundt
2007-05-10 13:08 ` Tejun Heo
2007-05-11 0:52 ` Paul Mundt
2007-05-11 9:39 ` Tejun Heo
2007-05-12 3:49 ` Paul Mundt
2007-05-16 0:30 ` Paul Mundt
2007-05-16 16:44 ` [PATCH] libata: implement ata_wait_after_reset() Tejun Heo
2007-05-17 0:50 ` Paul Mundt
2007-05-17 0:59 ` Paul Mundt
2007-05-19 15:54 ` Indan Zupancic
2007-05-19 18:23 ` Tejun Heo
2007-05-19 22:54 ` Indan Zupancic
2007-05-20 9:50 ` Tejun Heo
2007-05-20 13:26 ` Indan Zupancic
2007-05-20 17:09 ` Tejun Heo
2007-05-20 19:35 ` Indan Zupancic
2007-05-19 16:39 ` Indan Zupancic
2007-05-19 18:43 ` Tejun Heo
2007-05-19 19:04 ` Tejun Heo
2007-05-19 22:33 ` sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()] Indan Zupancic
2007-05-20 9:54 ` Tejun Heo
2007-05-20 14:27 ` Indan Zupancic
2007-05-20 17:17 ` Tejun Heo
2007-05-20 19:47 ` Indan Zupancic [this message]
2007-05-21 6:02 ` [PATCH] libata: implement ata_wait_after_reset() Paul Mundt
2007-05-29 1:31 ` Jeff Garzik
2007-05-29 7:33 ` Tejun Heo
[not found] <fa.M0o+I253i7tt/LF97sml0AM+Gec@ifi.uio.no>
[not found] ` <fa.j/gDhS9FZwWkX/stLhREkTHNbFs@ifi.uio.no>
[not found] ` <fa.EalQUMJMBHX/KTGV2QFQLG6tYus@ifi.uio.no>
[not found] ` <fa.Zh3ttZJ9A5tObhEjMLSALUpxCuQ@ifi.uio.no>
[not found] ` <fa.tQ9LHpM0TOYAYEug36HHMvEVOO0@ifi.uio.no>
[not found] ` <fa.jSmqI/kJPff3zaVtC404yNL5/Qk@ifi.uio.no>
2007-05-20 17:45 ` sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()] Robert Hancock
2007-05-20 18:53 ` Randy Dunlap
2007-05-20 22:25 ` Robert Hancock
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=3378.81.207.0.53.1179690453.squirrel@secure.samage.net \
--to=indan@nul.nu \
--cc=garyhade@us.ibm.com \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=lethal@linux-sh.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®