lkml.org 
[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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:4.103 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site