summaryrefslogtreecommitdiffstats
path: root/block/blk-flush.c
diff options
context:
space:
mode:
authorChristoph Hellwig <hch@lst.de>2023-07-14 16:30:14 +0200
committerJens Axboe <axboe@kernel.dk>2023-07-14 16:42:58 +0200
commit9f87fc4d72f52b26ac3e19df5e4584227fe6740c (patch)
tree58169b545b6aa86d4c746668169d64bcd24cf86d /block/blk-flush.c
parentMerge tag 'nvme-6.5-2023-07-13' of git://git.infradead.org/nvme into block-6.5 (diff)
downloadlinux-9f87fc4d72f52b26ac3e19df5e4584227fe6740c.tar.xz
linux-9f87fc4d72f52b26ac3e19df5e4584227fe6740c.zip
block: queue data commands from the flush state machine at the head
We used to insert the data commands following a pre-flush to the head of the queue until commit 1e82fadfc6b ("blk-mq: do not do head insertions post-pre-flush commands"). Not doing this seems to cause hangs of such commands on NFS workloads when exported from file systems with SATA SSDs. I have no idea why this would starve these workloads, but doing a semantic revert of this patch (which looks quite different due to various other changes) fixes the hangs. Fixes: 1e82fadfc6b ("blk-mq: do not do head insertions post-pre-flush commands") Reported-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Chuck Lever <chuck.lever@oracle.com> Link: https://lore.kernel.org/r/20230714143014.11879-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/blk-flush.c')
-rw-r--r--block/blk-flush.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/block/blk-flush.c b/block/blk-flush.c
index dba392cf22be..8220517c2d67 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -189,7 +189,7 @@ static void blk_flush_complete_seq(struct request *rq,
case REQ_FSEQ_DATA:
list_move_tail(&rq->flush.list, &fq->flush_data_in_flight);
spin_lock(&q->requeue_lock);
- list_add_tail(&rq->queuelist, &q->flush_list);
+ list_add(&rq->queuelist, &q->requeue_list);
spin_unlock(&q->requeue_lock);
blk_mq_kick_requeue_list(q);
break;