On Tue, Jan 21, 2014 at 8:18 AM, Dan Williams wrote:
> On Tue, Jan 21, 2014 at 7:44 AM, Alan Stern wrote:
>> On Tue, 21 Jan 2014, Dan Williams wrote:
>>
>>> On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern
>>> wrote:
>>> > On Fri, 17 Jan 2014, Dan Williams wrote:
>>> >
>>> >> I think it's a bit of a
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
On Tue, Jan 21, 2014 at 7:44 AM, Alan Stern wrote:
> On Tue, 21 Jan 2014, Dan Williams wrote:
>
>> On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern
>> 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
-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 a
On Tue, 21 Jan 2014, Phillip Susi wrote:
> 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
> >
On Tue, 21 Jan 2014, Dan Williams wrote:
> On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern 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
> >> n
-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
> lazy
On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern 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 the disk. For ata
-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 stora
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
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 cou
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
> sy
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 s
On Fri, Jan 17, 2014 at 7:18 PM, Phillip Susi 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
>> invalidated a
-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 hop
-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 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
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 th
On Fri, Jan 17, 2014 at 5:41 PM, Alan Stern 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 during
>> > sys
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,
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 runti
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 importa
On Fri, Jan 17, 2014 at 12:49 PM, Phillip Susi 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-demand
-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: 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-demand resume of the disk is that you incur the full
> resume latency ri
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 imme
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 6:57 AM, Alan Stern 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 attention to them and wil
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, 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.
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 f
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 th
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 can'
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 i
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
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
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
-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'
-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
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 n
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 d
41 matches
Mail list logo
