Re: [PATCH v5 3/4] block: implement runtime pm strategy

[Alan Stern]

On Fri, 6 Jul 2012, James Bottomley wrote:

> The mechanism is pretty much identical:  For quiesce you set the sdev
> state to SDEV_QUIESCE and then send in special requests with REQ_PREEMPT
> to bypass the suspend.  In your additional scheme you set a queue flag
> RPM_SUSPENDED by a pm specific set of callbacks and you only then accept
> requests with REQ_PM.  I don't see any difference in actual effect
> (well, except that quiesce can be done on a non-empty queue, but that's
> a simple flag difference).
> 
> What I don't want to see is duplicated mechanisms.  If you want to make
> a general quiesce mechanism in block instead of SCSI, I'm fine with
> that, but I want to see our current quiesce mechanism moved to it first
> since that demonstrates you got it right.  If you don't want to do that,
> then just use the existing mechanism in SCSI.

Moving the whole thing to block sounds like a good suggestion.  But are
the end results supposed to be the same?  For example, if a rotating
disk is put into the QUIESCE state, does it get spun down (as would
happen with a runtime suspend)?  I rather got the impression that
QUIESCE meant carrying out existing requests and not accepting new
ones, without the other actions needed for suspend.

What is the client interface for the quiesce mechanism?  There are a
few calls in scsi_transport_spi.c, but no other obvious entry points
besides sysfs.

Are you suggesting that writing "quiesce" to the state attribute should
drain the request queue and then initiate a runtime suspend?

> Now that I look at it, your q->nr_pending is an inexact duplicate of
> sdev->device_busy as well.  Again, no objection to moving this to block,
> but if you then make SCSI use it for sdev->device_busy, you'll get a
> very fast indication of whether you got this right or not, which is an
> excellent reason for unifying.

They aren't exactly the same, because nr_pending counts requests on the
queue whether or not they have been started at the SCSI level.  But
obviously they are closely related.

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/