On 10/17/2017 10:18 PM, Bart Van Assche wrote: > On Tue, 2017-10-17 at 08:33 +0200, Hannes Reinecke wrote: >> How do you ensure that PREEMPT requests are not stuck in the queue >> _behind_ non-PREEMPT requests? >> 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? > > Hello Hannes, > > The blk_mq_freeze_queue() / blk_mq_unfreeze_queue() calls that have been > added through patch 9/10 to scsi_device_quiesce() will only succeed after all > outstanding requests have finished. That includes non-preempt requests and > requests that are about to be requeued. The changes in scsi_device_quiesce() > are such that blk_queue_enter() will fail for non-preempt requests after the > queue has been unfrozen. In other words, if a scsi_device_quiesce() call > succeeds, it is guaranteed that there are no non-preempt requests in the queue > and also that no new non-preempt requests will enter the queue until > scsi_device_resume() is called. > Ah. Right.
That was the explanation I was after. Reviewed-by: Hannes Reinecke <h...@suse.com> Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
