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

Bart Van Assche
2018-07-16T16:03:04Z

On Sat, 2018-07-14 at 10:37 +0800, Ming Lei wrote:
> OK, I am thinking another idea for addressing this issue.
>=20
> We may introduce one logical admin(pm) request queue for each scsi=
8-device,
> and this queue shares tag with IO queue, with NO_SCHED set, and a=
lways
> use atomic mode of the queue usage refcounter. Then we may send PM
> command to device after the IO queue is frozen.
>=20
> Also PREEMPT_ONLY can be removed too in this way.
>=20
> Even in future, all pass-through commands may be sent to this admin q=
ueue.
>=20
> If no one objects, I will cook patches towards this direction.

Wouldn't it be overkill to introduce a separate admin queue for SCSI device=
s?
Will that new queue be visible under /sys/block as a request queue? If so,
how many scripts will break due to that sysfs change? If the new queue won'=
t
be visible under /sys/block, how many changes will have to be made to the
block layer to avoid that it becomes visible?

Regarding the device_busy, device_blocked, cmd_list and other a=
ttributes in
struct scsi_device: will the SCSI commands submitted to the admin queue=
affect
these attributes? If not, which assumptions in the SCSI core will break? An=
d
if SCSI commands submitted to the admin queue will affect these attributes,
how will these attributes be shared between the regular and the admin reque=
st
queues?

Since the power management core guarantees that runtime PM operations do no=
t
occur during suspend nor during resume operations: has it been considered t=
o
drop the RQF_PM flag and to use the RQF_PREEMPT flag instead and al=
so to
set and reset QUEUE_FLAG_PREEMPT_ONLY as needed?

Bart.