All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jens Axboe <axboe@kernel.dk>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	linux-pm@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org, Aaron Lu <aaron.lwe@gmail.com>,
	Shane Huang <shane.huang@amd.com>
Subject: Re: [PATCH v7 3/4] block: implement runtime pm strategy
Date: Thu, 17 Jan 2013 13:13:25 +0800	[thread overview]
Message-ID: <20130117051325.GA31469@aaronlu.sh.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1301161020190.1704-100000@iolanthe.rowland.org>

On Wed, Jan 16, 2013 at 10:30:45AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2013, Aaron Lu wrote:
> 
> > From: Lin Ming <ming.m.lin@intel.com>
> > 
> > When a request is added:
> >     If device is suspended or is suspending and the request is not a
> >     PM request, resume the device.
> > 
> > When the last request finishes:
> >     Call pm_runtime_mark_last_busy().
> > 
> > When pick a request:
> >     If device is resuming/suspending, then only PM request is allowed
> >     to go.
> > 
> > Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> > Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> 
> Just a couple of minor problems remaining...
> 
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> 
> > @@ -2051,6 +2063,28 @@ static void blk_account_io_done(struct request *req)
> >  	}
> >  }
> >  
> > +#ifdef CONFIG_PM_RUNTIME
> > +/*
> > + * Don't process normal requests when queue is suspended
> > + * or in the process of suspending/resuming
> > + */
> > +static struct request *blk_pm_peek_request(struct request_queue *q,
> > +					   struct request *rq)
> > +{
> > +	if (q->rpm_status == RPM_SUSPENDED ||
> > +	    (q->rpm_status != RPM_ACTIVE && !(rq->cmd_flags & REQ_PM)))
> > +		return NULL;
> > +	else
> > +		return rq;
> > +}
> 
> You don't check q->dev here, so the result is indefinite for devices
> that don't use runtime PM.  (Actually it will work out because
> RPM_ACTIVE is defined as 0, but that's a pretty fragile approach.)
> 
> Either do check q->dev here, or else explicitly initialize
> q->rpm_status when the queue is created.

I think I'll check q->dev, which is more clear.

> 
> 
> > --- a/block/elevator.c
> > +++ b/block/elevator.c
> > @@ -34,6 +34,7 @@
> >  #include <linux/blktrace_api.h>
> >  #include <linux/hash.h>
> >  #include <linux/uaccess.h>
> > +#include <linux/pm_runtime.h>
> >  
> >  #include <trace/events/block.h>
> >  
> > @@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q, struct request *rq,
> >  		e->type->ops.elevator_bio_merged_fn(q, rq, bio);
> >  }
> >  
> > +#ifdef CONFIG_PM_RUNTIME
> > +static void blk_pm_requeue_request(struct request *rq)
> > +{
> > +	if (!(rq->cmd_flags & REQ_PM))
> > +		rq->q->nr_pending--;
> > +}
> 
> You don't check q->dev here.  That's okay, but it means that
> q->nr_pending will be meaningless or wrong if any I/O takes place
> before blk_pm_runtime_init is called.

Right, so I had better check q->dev here too.

> 
> Therefore the kerneldoc for blk_pm_runtime_init should mention that it
> must not be called after any requests have been submitted.  Also

So with the q->dev check added above, I believe this is not needed.

> mention that blk_pm_runtime_init enables runtime PM for q->dev, so the 
> caller shouldn't do it.

OK, thanks for the suggestion.

-Aaron


  reply	other threads:[~2013-01-17  5:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16  9:02 [PATCH v7 0/4] block layer runtime pm Aaron Lu
2013-01-16  9:02 ` [PATCH v7 1/4] block: add a flag to identify PM request Aaron Lu
2013-01-16  9:02 ` [PATCH v7 2/4] block: add runtime pm helpers Aaron Lu
2013-01-16  9:02 ` [PATCH v7 3/4] block: implement runtime pm strategy Aaron Lu
2013-01-16 15:30   ` Alan Stern
2013-01-16 15:30     ` Alan Stern
2013-01-17  5:13     ` Aaron Lu [this message]
2013-01-17 15:11       ` Alan Stern
2013-01-17 15:11         ` Alan Stern
2013-01-18  8:27         ` Aaron Lu
2013-01-18 15:26           ` Alan Stern
2013-01-18 15:26             ` Alan Stern
2013-01-19  6:24             ` Aaron Lu
2013-01-19 18:11               ` Alan Stern
2013-01-19 18:11                 ` Alan Stern
2013-01-28  9:21                 ` Aaron Lu
2013-01-28 15:11                   ` Alan Stern
2013-01-17  6:31     ` Aaron Lu
2013-01-16  9:02 ` [PATCH v7 4/4] sd: change to auto suspend mode Aaron Lu
2013-01-18 21:25   ` Alan Stern
2013-01-18 21:25     ` Alan Stern
2013-01-21 12:44     ` Aaron Lu
2013-01-28  8:56     ` Aaron Lu
2013-01-28 15:12       ` Alan Stern
2013-01-28 15:12         ` 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=20130117051325.GA31469@aaronlu.sh.intel.com \
    --to=aaron.lu@intel.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aaron.lwe@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=shane.huang@amd.com \
    --cc=stern@rowland.harvard.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.