block: Requeue req as head if driver touched it
Subsystems (2)
PATCH v2 1/3 block: Requeue req as head if driver touched it
In case the driver set RQF_DONTPREP flag, requeue the request as head as it is likely that the backing storage already had a request to an adjacent region, so getting the requeued request out as soon as possible may give us some performance benefit.
The are various reasons a driver may requeue a request (and therefore RQF_DONTPREP being set).
One reason may be that the driver or the hardware cannot satisfy the block layer alignment/sizes.
This for example is the case with mmcblk with a host driver that cannot deal with multiple block transfers.
Consider a request for lba 42 for one page so 4K or 8 blocks. mmcblk will do a single block request for lba 42 and requeue for the rest if the host can only perform single block transfers. In this case the device only delivered 512 bytes of data at lba 42, but may have performed a readahead itself for the following lbas, or do an 'implicit' readahead as it only deals with larger block size mappings itself.
In that case it would be beneificial if the request for lba 43 and the rest of the remaining blocks follow immediately after the initial lba 42 request.
Requeueing already partially processed requests as head preserves the intended request order (unless the driver has a queue of its own) and therefore mitigates this problem .
---
-v2: Extended commit message with example use case, no code change
block/blk-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
block/blk-mq.c +1 -1
@@ -1429,7 +1429,7 @@ static void blk_mq_requeue_work(struct work_struct *work)* merge. */ if (rq->rq_flags &RQF_DONTPREP ) -blk_mq_request_bypass_insert (rq, false, false); +blk_mq_request_bypass_insert (rq, true, false);else blk_mq_sched_insert_request (rq, true, false, false); }
Signature · 4 lines
2.37.3 Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: Dr. Jan Peter Berns. Commercial register of local courts: Freiburg HRB381782
Quoted 27 lines · Christian Löhle
In case the driver set
RQF_DONTPREPflag, requeue the request as head as it is likely that the backing storage already had a request to an adjacent region, so getting the requeued request out as soon as possible may give us some performance benefit.The are various reasons a driver may requeue a request (and therefore
RQF_DONTPREPbeing set).
One reason may be that the driver or the hardware cannot satisfy the block layer alignment/sizes.This for example is the case with mmcblk with a host driver that cannot deal with multiple block transfers.
Consider a request for lba 42 for one page so 4K or 8 blocks. mmcblk will do a single block request for lba 42 and requeue for the rest if the host can only perform single block transfers. In this case the device only delivered 512 bytes of data at lba 42, but may have performed a readahead itself for the following lbas, or do an 'implicit' readahead as it only deals with larger block size mappings itself.
In that case it would be beneificial if the request for lba 43 and the rest of the remaining blocks follow immediately after the initial lba 42 request.
Requeueing already partially processed requests as head preserves the intended request order (unless the driver has a queue of its own) and therefore mitigates this problem .
Quoted 1 line
Signed-off-by Christian Loehle <[email protected]>
Thanks for updating the commit message!
As I said for v1, this seems reasonable to me, but I am deferring to Jens to get his opinion. Beyond that, I will have a look at pacth2 and patch3 too.
Kind regards
Uffe
Quoted 25 lines
---
(quoted diff) +0
-1-v2: Extended commit message with example use case, no code change block/blk-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)block/blk-mq.c +1
-2@@ -1429,7 +1429,7 @@ static void blk_mq_requeue_work(struct work_struct *work)* merge. */ if (rq->rq_flags &RQF_DONTPREP ) -blk_mq_request_bypass_insert (rq, false, false); +blk_mq_request_bypass_insert (rq, true, false);else blk_mq_sched_insert_request (rq, true, false, false); } --2.37.3
Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: Dr. Jan Peter Berns. Commercial register of local courts: Freiburg HRB381782