On Tue, Oct 17, 2017 at 08:33:36AM +0200, Hannes Reinecke wrote: > On 10/17/2017 01:29 AM, Bart Van Assche wrote: > > The contexts from which a SCSI device can be quiesced or resumed are: > > * Writing into /sys/class/scsi_device/*/device/state. > > * SCSI parallel (SPI) domain validation. > > * The SCSI device power management methods. See also scsi_bus_pm_ops. > > > > It is essential during suspend and resume that neither the filesystem > > state nor the filesystem metadata in RAM changes. This is why while > > the hibernation image is being written or restored that SCSI devices > > are quiesced. The SCSI core quiesces devices through scsi_device_quiesce() > > and scsi_device_resume(). In the SDEV_QUIESCE state execution of > > non-preempt requests is deferred. This is realized by returning > > BLKPREP_DEFER from inside scsi_prep_state_check() for quiesced SCSI > > devices. Avoid that a full queue prevents power management requests > > to be submitted by deferring allocation of non-preempt requests for > > devices in the quiesced state. This patch has been tested by running > > the following commands and by verifying that after resume the fio job > > is still running: > > > (We've discussed this at ALPSS already:) > > How do you ensure that PREEMPT requests are not stuck in the queue > _behind_ non-PREEMPT requests? Once the PREEMP_ONLY flag is set, blk_mq_freeze_queue() is called for draining up all requests in queue first, and new requests are prevented from being allocated meantime. So looks no such issue? > Once they are in the queue the request are already allocated, so your > deferred allocation won't work. > _And_ deferred requests will be re-inserted at the head of the queue. > Consequently the PREEMPT request will never ever scheduled during quiesce. > How do you avoid such a scenario? >From the implementation, no any PREEMPT request can be allocated once scsi_device_quiesce() returns. Also not see deferred requests in this patch, could you explain it a bit? -- Ming
