Re: [linux-pm] [PATCH] libata: skip EH autopsy and recovery duringsuspend

[Alan Stern]

On Fri, 3 Sep 2010, Tejun Heo wrote:

> > Tejun, I'm planning to make a few changes to the block layer and the
> > SCSI core in order to implement delayed autosuspend.  These changes
> > will affect system sleep too, so you may need to know about them.
> > 
> > Each request_queue structure will have an rpm_status variable that gets
> > updated as the corresponding device is suspended or resumed.  When the
> > status is SUSPENDING or RESUMING, requests will not be sent from the
> > request_queue to the driver unless they have cmd_type set to
> > REQ_TYPE_PM_SUSPEND or REQ_TYPE_PM_RESUME (actually I may combine those
> > two into a single REQ_TYPE_PM type).  If other types of request are
> > added to the queue when the status isn't ACTIVE, they will cause a
> > runtime resume to be started.
> > 
> > Initially this will affect only drivers using the SCSI layer.  
> > Commands sent during error handling won't be affected though, because
> > the SCSI error handler doesn't use requests or queues -- it sends
> > commands directly to the lower-level driver.
> > 
> > Does that all sound okay to you?
> 
> Hmm... I can't really tell much without looking at the actual patch
> but I'm a bit doubtful about using REQ_TYPE_* for suspend/resumes,
> well, for that matter, for any other purpose than actual IO requests.
> The current REQ_TYPE_PM_* are only used by ide and it's really messy.

Yes.  I'm hoping that these changes will help simplify IDE, but I 
haven't looked at it yet.

> Those special requests are very difficult to use in generic manner.
> ie. How should remapping / cloning drivers like md, dm and loopback
> handle them?

They should never need to handle them.  These requests get used only
for preparing a device to change power modes.  Logical devices don't
need them, only physical devices do.  For example, you can't put a
logical RAID device into low-power mode; all you can do is put the
underlying physical drives into low power.

>  They end up just being a mechanism for specific low
> level drivers to feed certain requests back to themselves to implement
> suspend/resume sequence and as there's no clear defined common usage,
> the meaning of those flags becomes ambiguous and confusing depending
> on drivers and so on.

With my changes there now will be a clear defined usage.

> Another issue is that power management is probably better handled as a
> sub problem of generic IO exception handling.  If you throw in
> hot[un]plugs and transport errors and consider what should happen when
> those events happen together, things get hairy if power management is
> not well integrated with the usual exceptionn handling.

I don't see why.  Power management is not exceptional.  The relation
with hot [un]plug is already taken care of.  Transport error recovery
will block runtime power management if it occurs while the device is at
full power; it is an issue only if it occurs during a power transition.  
The SCSI error handler should work okay since it doesn't send commands
through the block layer.

Alan Stern

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