On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 17 Jan 2014, Dan Williams wrote:
I think it's a bit of an interface surprise to have pm_runtime disable
have side effects only for scsi_disk devices. I think lazy_resume
needs to be an explicit attribute of
-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
On Tue, Jan 21, 2014 at 7:44 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 21 Jan 2014, Dan Williams wrote:
On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Fri, 17 Jan 2014, Dan Williams wrote:
I think it's a bit of an interface surprise to have
On Tue, 21 Jan 2014, Phillip Susi wrote:
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
On Tue, Jan 21, 2014 at 8:18 AM, Dan Williams dan.j.willi...@intel.com wrote:
On Tue, Jan 21, 2014 at 7:44 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 21 Jan 2014, Dan Williams wrote:
On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Fri, 17 Jan
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 servers rather see an improvement at reboot time.
For example by not re-enumerating all 40 / 80
-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
Hello,
On Fri, Jan 17, 2014 at 08:41:00PM -0500, 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.
To tell the truth, I'm not sure
Hello, Phillip.
On Fri, Jan 17, 2014 at 03:55:30PM -0500, Phillip Susi wrote:
What kind of use cases are we expecting for the lazy behavior?
Not all systems only have a single drive. There may be a tendency for
IO to the drive with the root fs on it after a resume, but multi drive
systems
On Fri, 17 Jan 2014, Dan Williams wrote:
I think it's a bit of an interface surprise to have pm_runtime disable
have side effects only for scsi_disk devices. I think lazy_resume
needs to be an explicit attribute of the disk. For ata devices any
command wakes up the drive. Perhaps we could
On Thu, 2014-01-16 at 11:59 -0500, 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 know
what
the best way is to
Hello,
On Fri, Jan 17, 2014 at 11:16:49AM +0100, Oliver Neukum wrote:
The START-STOP may result in an error. What do you do in that case?
At least for libata, worrying about suspend/resume failures don't make
whole lot of sense. If suspend failed, just proceed with suspend. If
the device
On Thu, 16 Jan 2014, Todd E Brandt wrote:
On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
On Thu, 16 Jan 2014, Todd E Brandt wrote:
Does this plan sound reasonable to everyone? Are there important
aspects I haven't considered (such as interactions between the SCSI and
On Fri, 17 Jan 2014, Tejun Heo wrote:
Hello,
On Fri, Jan 17, 2014 at 11:16:49AM +0100, Oliver Neukum wrote:
The START-STOP may result in an error. What do you do in that case?
At least for libata, worrying about suspend/resume failures don't make
whole lot of sense. If suspend failed,
On Fri, 2014-01-17 at 05:21 -0500, Tejun Heo wrote:
Hello,
On Fri, Jan 17, 2014 at 11:16:49AM +0100, Oliver Neukum wrote:
The START-STOP may result in an error. What do you do in that case?
At least for libata, worrying about suspend/resume failures don't make
whole lot of sense. If
Hello, James.
On Fri, Jan 17, 2014 at 10:39:37AM -0800, James Bottomley wrote:
The specific worry is the writeback cache. If the flush fails and we
power down with dirty blocks in the cache, those blocks are lost but the
filesystem still thinks they're committed. I think as long as you're
On Fri, Jan 17, 2014 at 6:57 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 16 Jan 2014, Todd E Brandt wrote:
My patch makes ata port and scsi disk resume 'non-blocking' (asynchronous
with respect to system resume). Which means once they're called the power
manager pays no more
On Fri, 17 Jan 2014, Dan Williams wrote:
Once dpm_resume of the disk is asynchronous, is there much incremental
gain by further deferring spin up? The drawback of doing on-demand
resume of the disk is that you incur the full resume latency right
when you need the data. System resume is a
On Fri, Jan 17, 2014 at 03:15:54PM -0500, Alan Stern wrote:
You will have to argue this point with Phillip.
If necessary, we could add a sysfs attribute to force a spin-up during
system resume. Or you could disable runtime PM for the disk, but that
has its own disadvantages.
Isn't
-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
On Fri, Jan 17, 2014 at 12:49 PM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/17/2014 2:31 PM, Dan Williams wrote:
Once dpm_resume of the disk is asynchronous, is there much
incremental gain by further deferring spin up? The drawback of
doing
On Fri, Jan 17, 2014 at 09:57:47AM -0500, Alan Stern wrote:
On Thu, 16 Jan 2014, Todd E Brandt wrote:
On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
On Thu, 16 Jan 2014, Todd E Brandt wrote:
Does this plan sound reasonable to everyone? Are there important
On Fri, Jan 17, 2014 at 03:24:33PM -0500, Tejun Heo wrote:
On Fri, Jan 17, 2014 at 03:15:54PM -0500, Alan Stern wrote:
You will have to argue this point with Phillip.
If necessary, we could add a sysfs attribute to force a spin-up during
system resume. Or you could disable runtime PM
On Fri, 17 Jan 2014, Tejun Heo wrote:
On Fri, Jan 17, 2014 at 03:15:54PM -0500, Alan Stern wrote:
You will have to argue this point with Phillip.
If necessary, we could add a sysfs attribute to force a spin-up during
system resume. Or you could disable runtime PM for the disk, but that
On Fri, Jan 17, 2014 at 5:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 17 Jan 2014, Tejun Heo wrote:
On Fri, Jan 17, 2014 at 03:15:54PM -0500, Alan Stern wrote:
You will have to argue this point with Phillip.
If necessary, we could add a sysfs attribute to force a spin-up
On Fri, 17 Jan 2014, Dan Williams 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.
To tell the truth, I'm not sure how useful this
-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
On Fri, Jan 17, 2014 at 7:18 PM, Phillip Susi ps...@ubuntu.com wrote:
-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
Folks:
I would like to tie together separate email threads regarding disk
spin-up time during system resume.
Todd has posted some patches to make spin-up occur asynchronously, thus
not delaying the return of the system to normal operation. Phillip and
I have been designing an approach to allow
On Thu, Jan 16, 2014 at 11:59:43AM -0500, Alan Stern wrote:
Folks:
I would like to tie together separate email threads regarding disk
spin-up time during system resume.
Todd has posted some patches to make spin-up occur asynchronously, thus
not delaying the return of the system to normal
-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
On Thu, 16 Jan 2014, Todd E Brandt wrote:
Does this plan sound reasonable to everyone? Are there important
aspects I haven't considered (such as interactions between the SCSI and
ATA layers)?
Alan Stern
Both approaches employ non-blocking resume of the scsi disks so why don't
On Thu, 16 Jan 2014, Phillip Susi wrote:
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
On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
On Thu, 16 Jan 2014, Todd E Brandt wrote:
Does this plan sound reasonable to everyone? Are there important
aspects I haven't considered (such as interactions between the SCSI and
ATA layers)?
Alan Stern
Both
38 matches
Mail list logo
