Re: Some thoughts on suspend/resume development

Re: Some thoughts on suspend/resume development

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1614 bytes --]

On Fri, 11 Mar 2005, Pavel Machek wrote:

> > This is why I'm in favor of power domains (power parents and children
> > that can be independent of physical device relations).  Power domains
> > are common for internal devices, not just external devices.  Still, if
> > you disable a physical parent, then the device is no longer operational.
> > Disable the usb host controller, and the external disk drive cannot be
> > used (in fact data may be lost).  So it's necessary to stop every child
> > device first, and generally also power it off if we can control the
> > power source.
> 
> I just don't see it like that.
> 
> Remember old scsi disks where formatting took half an hour? You may do
> something like
> 
> invoke scsi format operation
> power down usb controller
> <half an hour later>
> power up usb controller
> get the results
> 
> Now, that was probably bad example, but I do think some devices might
> do usefull work even with their parents disabled.

There's another aspect to it as well.  You can suspend the USB host
controller and then _still_ use the external disk, if the host controller
is automatically resumed when the next disk I/O request arrives.  Whereas
if you would stop the disk and its driver, the next I/O request might
simply languish in a plugged queue.  I suppose this would depend on
whether the disk driver was smart enough to leave its queue unplugged
under the right circumstances, so perhaps this isn't a great example.  
(And you're right about the possibility of data being lost -- although
it's pretty unlikely -- which makes this an even worse example.)

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Some thoughts on suspend/resume development

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Fri, 2005-03-11 at 11:42 -0500, Alan Stern wrote:
> On Fri, 11 Mar 2005, Pavel Machek wrote:
> 
> > > This is why I'm in favor of power domains (power parents and children
> > > that can be independent of physical device relations).  Power domains
> > > are common for internal devices, not just external devices.  Still, if
> > > you disable a physical parent, then the device is no longer operational.
> > > Disable the usb host controller, and the external disk drive cannot be
> > > used (in fact data may be lost).  So it's necessary to stop every child
> > > device first, and generally also power it off if we can control the
> > > power source.
> > 
> > I just don't see it like that.
> > 
> > Remember old scsi disks where formatting took half an hour? You may do
> > something like
> > 
> > invoke scsi format operation
> > power down usb controller
> > <half an hour later>
> > power up usb controller
> > get the results
> > 
> > Now, that was probably bad example, but I do think some devices might
> > do usefull work even with their parents disabled.

Yes, but at a logical (class) level the parent device would never be
disabled, right?  I guess it would be possible to model such a situation
if we take advantage of the driver class design.  I hadn't considered it
before, but I'll try to keep it in mind.  It would be interesting to see
how common it might be.

> 
> There's another aspect to it as well.  You can suspend the USB host
> controller and then _still_ use the external disk, if the host controller
> is automatically resumed when the next disk I/O request arrives.  Whereas
> if you would stop the disk and its driver, the next I/O request might
> simply languish in a plugged queue.  I suppose this would depend on
> whether the disk driver was smart enough to leave its queue unplugged
> under the right circumstances, so perhaps this isn't a great example.  
> (And you're right about the possibility of data being lost -- although
> it's pretty unlikely -- which makes this an even worse example.)
> 
> Alan Stern

Yes, so I think if we ensure that the parent device is enabled at a
logical level, and that the power source is active, it would be possible
to do such a thing.  I'm guessing this is something not to worry about
too much now; do you think so?

Thanks,
Adam



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Some thoughts on suspend/resume development

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1510 bytes --]

On Fri, 11 Mar 2005, Adam Belay wrote:

> > > Now, that was probably bad example, but I do think some devices might
> > > do usefull work even with their parents disabled.
> 
> Yes, but at a logical (class) level the parent device would never be
> disabled, right?  I guess it would be possible to model such a situation
> if we take advantage of the driver class design.  I hadn't considered it
> before, but I'll try to keep it in mind.  It would be interesting to see
> how common it might be.
> 
> > 
> > There's another aspect to it as well.  You can suspend the USB host
> > controller and then _still_ use the external disk, if the host controller
> > is automatically resumed when the next disk I/O request arrives.  Whereas
> > if you would stop the disk and its driver, the next I/O request might
> > simply languish in a plugged queue.  I suppose this would depend on
> > whether the disk driver was smart enough to leave its queue unplugged
> > under the right circumstances, so perhaps this isn't a great example.  
> > (And you're right about the possibility of data being lost -- although
> > it's pretty unlikely -- which makes this an even worse example.)
> > 
> > Alan Stern
> 
> Yes, so I think if we ensure that the parent device is enabled at a
> logical level, and that the power source is active, it would be possible
> to do such a thing.  I'm guessing this is something not to worry about
> too much now; do you think so?

Agreed.  As Patrick said, this is a corner case.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: Some thoughts on suspend/resume development

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5176 bytes --]


On Wed, 9 Mar 2005, Adam Belay wrote:

> On Wed, 2005-03-09 at 05:54 -0800, Patrick Mochel wrote:
> > On Tue, 8 Mar 2005, Adam Belay wrote:

> > In general, we will always want to try to power down children, but even if
> > we can't, we still want to try to power down the parents. They just have
> > to know when it's safe to do it, which requires some extra checking, but
> > recall that parent devices are less common than leaf devices and the
> > checks can be done for an entire class of devices (like all PCI-PCI
> > bridges) and re-used for each instance.
> >
> > All in all, though, this is a corner case, and not neceesary in the
> > immediate future.
>
> I think we need to power down the individual devices even if they don't
> have a driver.  Cutting off the power domain without first powering down
> its children may possibly reduce the operating life of the devices.  If
> the power domain is turned off then context is lost anyway, so nothing
> is gained by leaving them on.
>
> The ideal solution is to have a driver for every device to save and
> restore state (though not always possible).  The model I suggested
> (start, open, etc) allows the user to disable a device while keeping the
> driver bound to it.  Therefore, even if the user has decided to not use
> the device, its power can be properly managed anyway.

Agreed. To do this, we need some sort of default driver to save
configuration space, or to handle it by the bus's layer.

This was suggested a very long time ago, but the consensus was that it's
imperative that all drivers be the master of their own destiny, and that
we don't do e.g. pci_save_state() for every driver on their behalf. That
said, we can a) leave drivers to control the call when they're bound to a
device, b) do it by default for devices that don't have a driver, and c)
add some sort of blacklist for devices that are buggy and don't handle it
well.

> > > > This would be doing something like partial-tree suspends, but I'm not sure
> > > > if this is best done in the kernel or in userspace with a proper tool.
> > >
> > > The basic strategy would be to lower the state of each child device, and
> > > then when all children are in a lower state, lower the parent (the power
> > > domain) to the least common denominator power state.  I think this would
> > > have to be done in the kernel because userspace may not be able to
> > > operate during this transition.
> >
> > Why not?
>
> Lets say the userspace program is located on a storage device.  If the
> program disables the device, it may not be able to complete the process
> and disable the remaining devices (of course the access could enable the
> storage device again, but then the suspend will also fail).
> Furthermore, it may not be able to handle the resume procedure.  In
> short, I'm worried that a userspace utility will not be able to manage
> hardware that it requires for its own operation.

Fair enough, I was just wondering.

> > > > > A common problem facing all drivers that do auto suspend is how to set
> > > > > the inactivity timeout.  Two possible answers are: add an attribute
> > > > > file in the /sys/.../power directory (so different devices can have
> > > > > different timeouts), or add a driver module parameter (so all devices
> > > > > using the same driver will have the same timeout).
> > >
> > > Each class could have its own policies, complete with timeout values.  In
> > > sysfs, the user could select which policy should be used. (e.g. performance,
> > > normal, powersave).
> >
> > I would think it would be better to have a per-device policy that is
> > perhaps derived from the bus. You want a different timeout value for each
> > device state, which is bus-specific. The concepts of 'performance',
> > 'powersave', and 'normal' are policy decisions that are best left for the
> > UI. The only thing the kernel should care about are the specific values of
> > the timers. What each threshold is, is system-specific and should be able
> > to be adjusted. It should also be a requirement of the UI that it apply
> > the same policy (performanc, normal, powesave, etc) to all devices in a
> > specific class.
>
> So you'd like specific timer values to be sysfs entries?

Yes. The kernel should only implement the mechanism, not the policy or the
UI. That's what utilties are for. :)

> > For a parent device, remember that those are rare compared to the majority
> > of other device they are bridge devices that understand the semantics of
> > devices on the other side of them. It is up to them to decide if/when they
> > should power down, and how much.
>
> Ok, but they still need to show what power state they require of their
> parent device.  I suppose they should be responsible for knowing about
> the power-states of any parent bus-type they might have.

Yes. They play two roles - a client of one bus type and a host of another.
On the one hand, they're requiring power from someone, and on the other,
they're providing for a set of devices. For the former, they are not much
different than any other device on the bus; it's just that they have
different semantics for knowing when they can power off.


	Pat


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm