RE: SCSI dynamic power management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 Nov 2007, James Bottomley wrote:

> > Here's how it will work: scsi_prep_state_check() will see that the
> > device is in a suspended state (probably a substate of SDEV_QUIESCE).  
> > The return value will depend on the type of suspend:
> > 
> > 	For manual suspend or system suspend, the routine simply 
> > 	returns BLKPREP_KILL.
> > 
> > 	For autosuspend, the routine will submit a workqueue request
> > 	to autoresume the device and will return BLKPREP_DEFER.
> > 
> > The trick is somehow to allow the START-STOP UNIT commands get past 
> > this filter.  Is this what the REQ_PREEMPT flag is intended for?
> 
> Um, that model is pretty host centric ... we wouldn't be able to use
> that for power management of shared devices like SAS/SATA devices in an
> expander or FC devices.  The basic problem with power management of
> external devices (whether shared or not) is that it's not just what the
> host did to them, it's also what the environment or administrator did to
> them.

Well, think of this as "idle-device" management rather than power 
management.

It's no more host-centric than the existing code in sd_suspend().  
When I mentioned sending START-STOP UNIT commands above, that was a bit
sloppy.  What the code would actually do is call the high-level
driver's suspend method, which would then send the appropriate commands
to the device.  (Or maybe the code would simply call scsi_bus_suspend.)  
If sending START-STOP UNIT during a suspend is host-centric then
sd_suspend() is already guilty.


Regarding this thread's original question, the best idea I've come up
with so far is to store an extra flag in the scsi_device structure
indicating that a suspend or resume transition is underway.  When the
flag is set, commands with REQ_PREEMPT would be accepted.  If the
device is "suspended" and the flag is clear, then commands would be
delayed or killed in the prep function regardless of REQ_PREEMPT.  This 
scheme could potentially let unwanted commands go through, but I 
haven't been able to think of anything more suitable.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux