Messages in this thread | | | Date | Sun, 30 Oct 2022 13:19:10 -0700 | Subject | Re: [PATCH 1/3] blk-mq: remove redundant call to blk_freeze_queue_start in blk_mq_destroy_queue | From | Bart Van Assche <> |
| |
On 10/30/22 07:55, Jinlong Chen wrote: >>> So I think there is a redundant call to blk_freeze_queue_start(), we >>> just need to call blk_mq_freeze_queue_wait() after calling >>> blk_queue_start_drain(). >> >> I think it is on purpose that blk_queue_start_drain() freezes the >> request queue and never unfreezes it. So if you want to change this >> behavior it's up to you to motivate why you want to change this behavior >> and also why it is safe to make that change. See also commit >> d3cfb2a0ac0b ("block: block new I/O just after queue is set as dying"). > > I think there might be some misunderstanding. I didn't touch > blk_queue_start_drain(), so its behavior is not changed. What I have done > is just replacing blk_freeze_queue() with blk_mq_freeze_queue_wait() in > blk_mq_destroy_queue().
Hi Jinlong,
Does this mean that you want me to provide more information about what I wrote? Without this patch, blk_mq_destroy_queue() uses two mechanisms to block future I/O requests: 1. Set the flag QUEUE_FLAG_DYING. 2. Freeze the request queue and leave it frozen.
Your patch modifies blk_mq_destroy_queue() such that it unfreezes the request queue after I/O has been quiesced instead of leaving it frozen. I would appreciate it if Ming Lei (Cc-ed) could comment on this change since I think that Ming introduced (2) in blk_mq_destroy_queue() (formerly called blk_cleanup_queue()).
Thanks,
Bart.
| |