[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-pm] Power management for SCSI
On Tue, 19 Aug 2008, Oliver Neukum wrote:

> > More to the point is whether you should ever suspend any of these
> > devices if there can be multiple initiators. But that's a separate
> > question.
> But one that needs to be addressed.

One possibility is to have an attribute flag for SCSI transport
classes, indicating whether the transport supports multiple initiators.

Besides, isn't this already an issue? What happens when someone does a
system suspend or hibernate? Don't the attached disk drives get spun
down, even if there are other initiators on the same SCSI bus?

(And is this really a problem? If an error occurs because a drive is
spun down when some other device tries to access it, that other device
should simply spin the drive back up again.)

> > What is your point? You seem to be saying that it would be nice to
> > suspend a host adapter at times when some of the SCSI targets beneath
> > it are not suspended. I agree, but how would you determine whether
> > such a thing was safe?
> I suggest by talking to the HLDs.

Why would the HLD (= ULD?) know?

For example, consider a USB disk drive. How is sd.c (the HLD) supposed
to know that it's not safe to suspend the USB link without spinning
down the drive? Or consider a traditional SCSI parallel interface
drive. How is sd.c supposed to know that it is safe to suspend the
SPI host adapter without first spinning down the drive?

> It seems to me that abstractly talking there are three criteria for suspension
> - the cpu needs to talk to the device now

I.e., whether the idle timeout has expired, right?

> - the device may need to talk to the CPU at unpredictable times

I.e, whether remote wakeup needs to be enabled, right?

> - suspending has side effects

I'm not sure what you mean by that. Suspension always has side effects
of one kind or another.

> Suspension in USB has always side effects. That's not true for other
> subsystems.

Name one. At the very least, suspending a device means you can't use
it again without first calling the driver's resume method. That's a
side effect.

Hopefully, in most subsystems suspending a device would reduce its
power usage. Unfortunately this isn't true for SCSI at the moment...

> It seems to me that for the general case we need to divorce
> the notion of a child being suspended itself from a child agreeing to its
> parent being suspended.

This is already possible. For example, you may remember a couple of
years ago I posted a patch for usb-storage which would autosuspend it
without regard for the state of its child devices. The patch didn't
work out, because some devices really did need to have their caches
drained or disks spun down.

There's nothing about my suspend framework to prevent a driver from
autosuspending its device while the children are still active.
Rather, the framework insists on notifications going the other way:
The driver has to be told whenever one of its device's children is
suspended or resumed.

Alan Stern

 \ /
  Last update: 2008-08-19 17:31    [W:0.123 / U:23.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site