linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Oliver Neukum <oliver@neukum.org>
Cc: Huang Ying <ying.huang@intel.com>, <ming.m.lin@intel.com>,
	<linux-kernel@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	James Bottomley <JBottomley@parallels.com>
Subject: Re: [RFC 0/5] scsi, sd, pm, request based runtime PM for scsi disk
Date: Sun, 12 Feb 2012 13:05:51 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1202121255400.18114-100000@netrider.rowland.org> (raw)
In-Reply-To: <201202112037.07173.oliver@neukum.org>

On Sat, 11 Feb 2012, Oliver Neukum wrote:

> > Your whole approach is at the wrong level.  Runtime PM between I/O 
> > requests for block devices should be implemented in the block layer, 
> > not in the SCSI layer.
> 
> I must disagree. The block layer has no more information than the SCSI
> layer and lacks everything the lower layers know.

But the block layer handles all block devices, not just SCSI ones.  You 
would end up duplicating code unnecessarily.

What pertinent information is known by the SCSI and lower layers but
not the block layer?

> It seems to me that most of these difficulties go away if we strictly
> differentiate between host adapter and disks.

To be more precise, you mean "disk drives".  You can suspend a drive,
but you can't suspend a disk.

> First, the sr driver cannot really suspend a disk. It can spin down a disk,
> but that is not the same thing as suspending, because the disk is still
> functional. It may just return special sense codes. The sr driver just
> prepares devices for suspension.

True.  This is because the SCSI standard does not include any notion of 
device suspension -- at least, not in the versions I'm aware of.

> It is true, that the sr driver probably does have a few conditions under
> which a device should not be suspended (eg. error handling) but it
> lacks positive knowledge about when we may suspend.
> 
> The same is also true for any higher layer.

Then what's wrong with handling runtime suspend in the higher layers?

> The problem of needing to do IO for suspension goes away if we
> treat the disk as always suspendable and use an active command
> as a condition for not suspending the storage device as opposed to the disk
> the problem goes away.

I don't entirely understand.  What's the difference between "the
storage device" and "the disk"?

However, using an active command as the condition is not the right 
thing to do.  It would use extra energy and slow everything down to 
suspend and resume the device between every pair of commands that were 
separated by a slight time delay.  There needs to be a timeout.

Furthermore, if you use active commands as the condition for 
suspending, what do you do when the act of suspending causes a command 
to be sent?  It is necessary to distinguish between ordinary commands 
and those that are PM-related.

Alan Stern


  reply	other threads:[~2012-02-12 18:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-06  7:32 [RFC 0/5] scsi, sd, pm, request based runtime PM for scsi disk Huang Ying
2012-02-06  7:32 ` [RFC 1/5] pm, runtime, Add resume notifier Huang Ying
2012-02-06  7:32 ` [RFC 2/5] scsi, pm, rename scsi_autopm_get/put_xxx to scsi_autopm_get/put_xxx_sync Huang Ying
2012-02-06  7:32 ` [RFC 3/5] scsi, pm, add pm_runtime_get/put in scsi request function Huang Ying
2012-02-06  7:32 ` [RFC 4/5] scsi, pm, use autosuspend for scsi runtime PM Huang Ying
2012-02-06  7:32 ` [RFC 5/5] scsi, sd, pm, request based runtime PM support Huang Ying
2012-02-06 15:13 ` [RFC 0/5] scsi, sd, pm, request based runtime PM for scsi disk Alan Stern
2012-02-07  4:59   ` Huang Ying
2012-02-11 19:37   ` Oliver Neukum
2012-02-12 18:05     ` Alan Stern [this message]
2012-02-12 20:00       ` Oliver Neukum
2012-02-13  1:42         ` Alan Stern
2012-02-13  9:28           ` Oliver Neukum
2012-02-13 15:20             ` Alan Stern
2012-02-18 20:44         ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1202121255400.18114-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=JBottomley@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=oliver@neukum.org \
    --cc=rjw@sisk.pl \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).