-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/05/2014 03:17 PM, Dan Williams wrote:
From: Todd Brandt todd.e.bra...@linux.intel.com
Improve overall system resume time by making libata link recovery
actions asynchronous relative to other resume events.
Link resume operations are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/19/2014 06:46 PM, Phillip Susi wrote:
I realize this is a little late but I finally started looking at
the patch set I was working on last year again, and now that I look
at your version that was accepted, I realize that it only addresses
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/10/2014 04:59 PM, Alan Stern wrote:
Why? The existing code doesn't have anything like that.
The current sd code doesn't, but the libata code does use the AHCI
staggered spinup feature flag as a hint to only spin up one drive at a
time, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is it possible to use the scsi_debug module to create more than one
device? It seems to me that it needs rewritten to have an interface
to dynamically create devices and set their parameters with a tool
like losetup, rather than using module
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/7/2014 3:46 PM, Martin K. Petersen wrote:
The question is how much sense it makes to invest in scsi_debug now
that we have the LIO target in the kernel?
Thanks, I hadn't heard of this. It looks interesting, though a bit
complicated.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/21/2014 5:12 AM, Dan Williams wrote:
The need is to avoid tying rpm and dpm ops together in surprising
new ways that require userspace to change if it wants to keep the
default behavior of hiding resume latency as much as possible. A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/21/2014 11:03 AM, Alan Stern wrote:
However, there is a compromise. The user gets to select the
autosuspend delay. If that delay is set to a very large value, it
will effectively prevent autosuspends from occurring, without
causing an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/20/2014 7:38 AM, CrashPlan Pro wrote:
Dan Williams wrote at 18-01-14 05:09:
Larger systems are less likely to ever sleep.
I have to agree with this. There is almost no storage server that
will be suspended to sleep.
Users of storage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/17/2014 3:24 PM, Tejun Heo wrote:
Isn't immediate spin-up trivial to implement from anywhere? I'm
not sure whether we'll end up defaulting to the lazy behavior or
not but if we do requiring userland to echo something to sysfs to
configure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 05:17 PM, Dan Williams wrote:
Well, at all is overstating it. The system was idle and now
it's being woken up to do some work. Inactivity timers are
invalidated and now the decision becomes minimize access latency,
or lazily wake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 08:24 PM, Todd E Brandt wrote:
10 seconds?! The only possible way that could happen is if the test
unit ready SCSI command actually triggered an ata port wakeup; at
which point you've already done the one thing you were trying not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 08:41 PM, Alan Stern wrote:
The intention is that this will help on systems with more than one
disk drive. The one containing the core OS files and the journal
will certainly spin up right away, but the others may not.
I am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/16/2014 1:04 PM, Todd E Brandt wrote:
Both approaches employ non-blocking resume of the scsi disks so why
don't we treat these two patch sets as parts one and two. My patch
just spins everything up but sets everything to non-blocking, so it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/16/2014 11:59 AM, Alan Stern wrote:
Since the START-STOP and TEST UNIT READY (or REQUEST SENSE or
whatever) commands are likely to take a long time, they should all
be carried out asynchronously with respect to the resume procedure.
I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/10/2014 12:23 AM, Douglas Gilbert wrote:
It is a command in the Sense Data Reporting feature set which is
optional for ATA devices and P as in Prohibited for ATAPI
devices. See the Feature set summary table.
Oops, you're right.
You had me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/10/2014 06:11 PM, Brandt, Todd E wrote:
Yes yours is simpler, but it also opens a potential memory issue
by passing a static int as the return location for the error value.
I think it's just safer to tell the callback to attempt no return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 10:40 AM, Alan Stern wrote:
We should change the code in the block layer. blk_pm_peek_request
should allow requests with REQ_PM set to go through, no matter
what the rpm_status is. Then the disk driver could query the disk
(to see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 11:14 AM, Alan Stern wrote:
That's true, but it isn't a problem. We know that requests with
REQ_PM are sent only at certain, controlled times. In particular,
the only time such a request would be sent while the disk is
RPM_SUSPENDED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 7:56 PM, Todd E Brandt wrote:
On resume, the ATA port driver currently waits until the AHCI
controller finishes executing the port wakeup command. This patch
changes the ata_port_resume callback to issue the wakeup and then
return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 1:29 PM, Douglas Gilbert wrote:
When REQUEST SENSE had its original semantics, TEST UNIT READY was
the only game in town for monitoring power management. From my
reading of spc4r36n.pdf section 5.1.2 Important commands for all
SCSI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 2:00 AM, Aaron Lu wrote:
Then I would say we just keep the pm_request_resume call in their
system resume callback. For drives that have that cool feature
turned on, it will be in runtime active state while it's actually
in standby
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 12:46 PM, Alan Stern wrote:
I/O _was_ done. To spin up the disk requires sending it a START
command. That's I/O.
Yes, currently, but that's exactly what I'm trying to get rid of.
In essence, you want your disk's state to move
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 4:21 PM, Alan Stern wrote:
I never saw your patches. Where were they posted?
Higher up in this thread on linux-ide and linux-scsi. Subject was Let
sleeping disks lie.
If you issue the REQUEST SENSE command in the usual way (going
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 2:49 AM, Aaron Lu wrote:
We can modify the device's system resume callback. To better
illustrate the idea, I just made two patches to do this and I did
some quick tests and didn't find anything wrong.
That misses one key aspect I was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:20 AM, Alan Stern wrote:
This raises two questions:
Should the host's resume be allowed to complete while the host is
still in error recovery? Wouldn't it be better to wait until the
recovery is finished?
Ahh, right, my other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:25 AM, Alan Stern wrote:
This doesn't seem like a good idea. The way to speed up resumes is
to allow sd's resume routine to return while the disk is still
spinning up (i.e., make the spin-up asynchronous). There already
have been
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 11:08 AM, Alan Stern wrote:
Okay, that's a different matter. There's a much simpler way to
accomplish this. The patch below will avoid spinning up drives
that were already in runtime suspend when the system sleep started.
(If a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 1:05 PM, Alan Stern wrote:
I disagree with your argument. If you aren't using autosuspend at
all then you don't mind having your disks spin all the time.
Therefore you don't mind if the disks spin up during system
resume.
I prefer to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 02:18 PM, Alan Stern wrote:
I don't know how you manually spin down your disk, but one
reasonable way to do it is to set the autosuspend timeout to 0. If
you use this approach and apply my patch, the disk should remain
spun down
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 08:03 PM, Aaron Lu wrote:
You mean you want to leave the disk runtime suspended after a
system resume and in the meantime make sure the disk is indeed not
spun up?
Yep. If it is spun up, then the runtime status should be updated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 08:32 PM, Aaron Lu wrote:
The ATA and SCSI devices are all resumed in my patches, notice
there is a single pm_request_resume call in both ATA and SCSI's
system resume callback, so the runtime status and the disk's state
is synced.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 09:11 PM, Aaron Lu wrote:
I thought that feature is used to control if a disk should be spun
up once powered from the host side.
That *is* what it sounds like, only ATA disks either spin up as soon
as power is applied, or wait for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 09:36 PM, Aaron Lu wrote:
I think the host controller can decide not to power all its ports,
only when a specific reg in the port's memory range is set, it will
give power to that port and thus spin up the drive. Makes sense?
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/6/2014 4:15 AM, Aaron Lu wrote:
My guess why it doesn't work for you is that, when you call
blk_pre_runtime_suspend in sd_resume_work, there are requests left
in the queue so that call will simply fail, it's not meant to be
used that way.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/06/2014 10:38 AM, Alan Stern wrote:
Indeed. I can't see any place where the SCSI or block layers
would stop the queue of a device when it gets runtime suspended.
Maybe some other layer is doing this.
So I've stepped through it in qemu a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/16/2013 06:30 PM, Phillip Susi wrote:
For some reason, the system hangs on resume if I issue the REQUEST
SENSE command after blk_pre_runtime_suspend. My understanding is
that the REQ_PM flag should make the command process even though
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 7:15 AM, Tejun Heo wrote:
On Mon, Nov 11, 2013 at 12:08:49PM -0500, Phillip Susi wrote:
No, I did not tune my system; I fixed the kernel so that
userspace's activities do not start those disks.
So, umm, implementing things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 1:43 AM, James Bottomley wrote:
-static int sd_resume(struct device *dev) +static int
sd_resume_runtime(struct device *dev) { struct scsi_disk *sdkp =
scsi_disk_get_from_dev(dev); int ret = 0;
-if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 12:48 PM, James Bottomley wrote:
Yes, they say that in sd_resume, if we're managing the disk start
stop, spin it up. Removing them spins everything up
unconditionally.
Ahh, right, I got rid of the manage_start_stop check. Probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 1:02 PM, Sergei Shtylyov wrote:
Isn't it an optional command, belonging to the power management
feature set?
Seems to be required. ATA-8 section 4.16 says:
A General feature set device shall implement power management
-BEGIN
is that the
REQ_PM flag should make the command process even though the queue is
RPM_SUSPENDING, but it doesn't seem to work. Anyone have any idea why?
Phillip Susi (6):
libata: use sleep instead of standby command
libata: avoid waking disk for several commands
libata: resume in the background
Don't block the resume path waiting for the disk to
spin up.
---
drivers/ata/libata-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8f856bb..4a28caf 100644
--- a/drivers/ata/libata-core.c
+++
Disks with Power Up In Standby enabled that required the
SET FEATURES command to start up were being issued the
command during resume. Suppress this until the disk
is actually accessed.
---
drivers/ata/libata-core.c | 12 ++--
drivers/ata/libata-eh.c | 10 --
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index db6dfcf..f92eb21
When a disk is in SLEEP mode it can not respond to any
commands. Instead of waking up the sleeping disk, fake the
commands. The commands include:
CHECK POWER
FLUSH CACHE
SLEEP
STANDBY IMMEDIATE
IDENTIFY
If we konw the disk is sleeping, we don't need to wake it up
to to find out if it is in
Instead of forcing a disk to start up with the START STOP UNIT
command when the system resumes, let it stay asleep if runtime
pm is enabled, and it will start the drive when it is accessed.
Query the drive to see if it starts up on its own ( like most
ATA disks do ) and update the runtime pm
SAT-3 says REQUEST SENSE should issue CHECK POWER and return
a sense status indicating the drive's power status.
---
drivers/ata/libata-scsi.c | 40 ++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-scsi.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/17/2013 3:33 PM, Todd E Brandt wrote:
sd_resume patch (2/2):
On resume, the SD driver currently waits until the block driver
finishes executing a disk start command with blk_execute_rq. This
patch changes the sd_resume callback to use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/20/2013 09:48 AM, Phillip Susi wrote:
My original idea was actually to just have the system resume force
the runtime pm status to suspended, then it will take care of
calling the runtime resume which can easily start the drive, but I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2013 9:23 AM, Mark Lord wrote:
Yeah, solve that, and you're golden. I totally understand the
motivation for this patch, and would love to have it working on my
machines here too.
But it may have to be some kind of sysfs optional
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2013 8:06 PM, Phillip Susi wrote:
I don't see anything particularly inefficient about issuing the
command in the eh path ( in fact, libata always uses the eh path to
handle power management ). You can of course, use the
manage_start_stop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2013 01:43 AM, James Bottomley wrote:
OK, so three people have now told you that's not how the code
works. Why don't you just read it? because there's not really much
point us reading your patches until you do.
I have, which is why I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2013 06:54 PM, Douglas Gilbert wrote:
Even if the SCSI EH code does spin-up the disk, it is inefficient
and undesirable to send a device into EH for what is a normal,
predictable situation (i.e. that a SCSI disk will need a START STOP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2013 07:09 PM, James Bottomley wrote:
Because you don't damn well listen. Two emails ago I said:
The error handler is not automatically activated for a not
ready/initializing command required because of multi-path
And I replied that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/16/2013 12:23 AM, Mark Lord wrote:
Ditto for many SATA disks with power up in standby enabled.
Ditto for my previous response; the kernel ( in this case the libata
layer ) notices this and takes care of starting it. The third patch I
posted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/16/2013 01:20 PM, James Bottomley wrote:
No disk does, neither SCSI nor ATA. The error handler is not
automatically activated for a not ready/initializing command
required because of multi-path. We override the default behaviour
via
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 8:08 AM, Sergei Shtylyov wrote:
-unsigned manage_start_stop:1;/* Let HLD (sd) manage
start/stop */ +unsigned manage_start_stop:2;/* Let HLD
(sd) manage start/stop */
I think you should better document this 2-bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 11:59 AM, Todd E Brandt wrote:
500ms is actually quite alot when you compare it with android or
iOS, or even with other subsystems like USB. USB is the second
worst offender after SATA disks and it tends to take around 600ms
for most
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/08/2013 08:20 PM, Todd E Brandt wrote:
I tested your patches and they do function. We tried a similar
approach a few months back where instead of waking the scsi disks
we just set them all to runtime_suspended and skipped the resume.
Then
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 97a0cef..79b75fd
like to just have return the
cached identify block, but am not sure how to get from the
qc's scattergather list to a memory pointer I can memcpy to.
Phillip Susi (6):
libata: use sleep instead of standby command
libata: avoid waking disk to check power
sd: don't bother spinning up disks
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if
The sd driver issues a flush cache when suspending, and this was causing
a sleeping drive to wake up for no reason. Another sleep or standby
command when the drive is already sleeping obviously should also not cause
the disk to spin up.
---
drivers/ata/libata-core.c | 6 +-
1 file changed, 5
Don't bother forcing disks to spin up on resume, as they
will do so automatically when accessed, and forcing them
to spin up slows down the resume. Add a second bit to the
manage_start_stop flag to restore the previous behavior.
---
drivers/scsi/sd.c | 6 +++---
Don't block the resume path waiting for the disk to
spin up.
---
drivers/ata/libata-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 686c441..128ce0d 100644
--- a/drivers/ata/libata-core.c
+++
Disks with Power Up In Standby enabled that required the
SET FEATURES command to start up were being issued the
command during resume. Suppress this until the disk
is actually accessed.
---
drivers/ata/libata-core.c | 12 ++--
drivers/ata/libata-eh.c | 10 --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/7/2013 1:21 PM, Douglas Gilbert wrote:
On 13-11-06 08:57 PM, Phillip Susi wrote:
Don't bother forcing disks to spin up on resume, as they will do
so automatically when accessed, and forcing them to spin up slows
down the resume. Add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/6/2013 12:49 AM, Aaron Lu wrote:
Todd has been optimising system resume for SATA drives without
touching runtime PM:
http://www.spinics.net/lists/linux-scsi/msg69532.html You may want
to take a look.
Thanks for the pointer, but is there
Don't bother forcing disks to spin up on resume, as they
will do so automatically when accessed, and forcing them
to spin up slows down the resume. Add a second bit to the
manage_start_stop flag to restore the previous behavior.
---
drivers/scsi/sd.c | 6 +++---
Don't block the resume path waiting for the disk to
spin up.
---
drivers/ata/libata-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 573d151..16f45dc 100644
--- a/drivers/ata/libata-core.c
+++
Disks with Power Up In Standby enabled that required the
SET FEATURES command to start up were being issued the
command during resume. Suppress this until the disk
is actually accessed.
---
drivers/ata/libata-core.c | 10 +++---
drivers/ata/libata-eh.c | 11 +++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2013 4:05 AM, Aaron Lu wrote:
Are you using an ATA drive? Last time I checked, the spin up
actually happened while the ata port is resumed(when it will be
reset): https://lkml.org/lkml/2013/2/4/361
Why does resetting the port spin up the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2013 10:56 AM, Douglas Gilbert wrote:
I think that you might find that almost any SCSI command
(translated to its ATA equivalent command) will wake up a SATA
disk. Perhaps just this sequence: fd = open(ata_bloc_device) ;
close(fd) ; is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2013 4:05 AM, Aaron Lu wrote:
Are you using an ATA drive? Last time I checked, the spin up
actually happened while the ata port is resumed(when it will be
reset): https://lkml.org/lkml/2013/2/4/361
Is there a reason these patches weren't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I found the culprit. It seems that ata_port_reset identifies the
device, and if it has power up in standby enabled, and requires the
SET FEATURES command to spin up, issues the command right away. I wonder:
1) If the spinup command can't be
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
Signed-off-by: Phillip Susi ps...@ubuntu.com
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b
if they
are awake or not before trying to read their smart status.
Signed-off-by: Phillip Susi ps...@ubuntu.com
---
drivers/ata/libata-core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83b1a9f..573d151 100644
--- a/drivers/ata
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I can not figure out what is waking up disks on resume from suspend.
I thought it was sd.c, and setting manage_start_stop = 0 should stop
that. It does stop the message printed saying it is being started,
yet the disk is still started, and this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/04/2013 09:23 PM, Aaron Lu wrote:
I suppose this is mainly for runtime PM? Since for system
suspend/hibernation, the disk and its controller will be powered
off anyway.
Yes, or the second patch also helps when one manually issues hdparm
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/04/2013 09:39 PM, Aaron Lu wrote:
If the disk entered sleep mode due to runtime PM, then udisks can
easily tell by checking the device's runtime status and not send
out the query.
But if the disk entered sleep mode due to other reason,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have been trying out the new block layer runtime pm, and run into a
problem: udisks keeps waking up the disk. Every 10 minutes it tries
to poll the SMART status of the drive, but it does first issue an ata
CHECK POWER command to see if it is in
81 matches
Mail list logo
