On Wed, Apr 19, 2023 at 03:43:41PM -0700, Bart Van Assche wrote: >> As said before this is not correct. What we need to instead is to >> support proper patch insertation when the at_head flag is set so >> that the requests get inserted before the existing requests, but >> in ordered they are passed to the I/O scheduler. > > It is not clear to me how this approach should work if the AT_HEAD flag is > set for some zoned writes but not for other zoned writes for the same zone? > The mq-deadline scheduler uses separate lists for at-head and for other > requests. Having to check both lists before dispatching a request would > significantly complicate the mq-deadline scheduler. > >> This also needs to be done for the other two I/O schedulers. > > As far as I know neither Kyber nor BFQ support zoned storage so we don't > need to worry about how these schedulers handle zoned writes? The problem is that we now run into different handling depending on which kind of write is coming in. So we need to find a policy that works for everyone. Remember that as of the current for-6.4/block branch the only at_head inservations remaining are: - blk_execute* for passthrough requests that never enter the I/O scheduler - REQ_OP_FLUSH that never enter the I/O scheduler - requeues using blk_mq_requeue_request - processing of the actual writes in the flush state machine with the last one going away in my RFC series. So if we come to the conclusion that requeues from the driver do not actually need at_head insertations to avoid starvation or similar we should just remove at_head insertations from the I/O scheduler. If we can't do that, we need to handle them for zoned writes as well.