Re: [PATCH RFC V2 0/3] blk-mq: support runtime PM

Ming Lei
2018-07-14T02:37:51Z

On Fri, Jul 13, 2018 at 08:21:09AM -0600, Jens Axboe wrote:
> On 7/13/18 2:05 AM, Ming Lei wrote:
> > Hi Guys,
> >
> > Runtime PM is usually enabled for SCSI devices, and we are switching to
> > SCSI_MQ recently, but runtime PM isn't supported yet by blk-mq, and
> > people may complain that.
> >
> > This patch tries to support runtime PM for blk-mq. And one chanllenge is
> > that it can be quite expensive to account the active in-flight IOs for
> > figuring out when to mark the last busy. This patch simply marks busy
> > after each non-PM IO is done, and this way is workable because:
> >
> > 1) pm_runtime_mark_last_busy() is very cheap
> >
> > 2) in-flight non-PM IO is checked in blk_pre_runtime_suspend(), so
> > if there is any IO queued, the device will be prevented from being
> > suspened.
> >
> > 3) Generally speaking, autosuspend_delay_ms is often big, and should
> > be in unit of second, so it shouldn't be a big deal to check if queue
> > is idle in blk_pre_runtime_suspend().
> >
> >
> > V2:
> > - re-organize code as suggested by Christoph
> > - use seqlock to sync runtime PM and IO path
>
> See other mail on why this is not going to be acceptable.

OK, I am thinking another idea for addressing this issue.

We may introduce one logical admin(pm) request queue for each scsi_device,
and this queue shares tag with IO queue, with NO_SCHED set, and always
use atomic mode of the queue usage refcounter. Then we may send PM
command to device after the IO queue is frozen.

Also PREEMPT_ONLY can be removed too in this way.

Even in future, all pass-through commands may be sent to this admin queue.

If no one objects, I will cook patches towards this direction.

Thanks,
Ming