From: Tatyana Brokhman <[email protected]>
Add support for reinserting a dispatched request back to the
scheduler's internal data structures.
This capability is used by the device driver when it chooses to
interrupt the current request transmission and execute another (more
urgent) pending request. For example: interrupting long write in order
to handle pending read. The device driver re-inserts the
remaining write request back to the scheduler, to be rescheduled
for transmission later on.
Add API for verifying whether the current scheduler
supports reinserting requests mechanism. If reinsert mechanism isn't
supported by the scheduler, this code path will never be activated.
Signed-off-by: Tatyana Brokhman <[email protected]>
diff --git a/block/blk-core.c b/block/blk-core.c
index 186603b..d66b387 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1217,6 +1217,50 @@ void blk_requeue_request(struct request_queue *q, struct request *rq)
}
EXPORT_SYMBOL(blk_requeue_request);
+/**
+ * blk_reinsert_request() - Insert a request back to the scheduler
+ * @q: request queue
+ * @rq: request to be inserted
+ *
+ * This function inserts the request back to the scheduler as if
+ * it was never dispatched.
+ *
+ * Return: 0 on success, error code on fail
+ */
+int blk_reinsert_request(struct request_queue *q, struct request *rq)
+{
+ if (unlikely(!rq) || unlikely(!q))
+ return -EIO;
+
+ blk_delete_timer(rq);
+ blk_clear_rq_complete(rq);
+ trace_block_rq_requeue(q, rq);
+
+ if (blk_rq_tagged(rq))
+ blk_queue_end_tag(q, rq);
+
+ BUG_ON(blk_queued_rq(rq));
+
+ return elv_reinsert_request(q, rq);
+}
+EXPORT_SYMBOL(blk_reinsert_request);
+
+/**
+ * blk_reinsert_req_sup() - check whether the scheduler supports
+ * reinsertion of requests
+ * @q: request queue
+ *
+ * Returns true if the current scheduler supports reinserting
+ * request. False otherwise
+ */
+bool blk_reinsert_req_sup(struct request_queue *q)
+{
+ if (unlikely(!q))
+ return false;
+ return q->elevator->type->ops.elevator_reinsert_req_fn ? true : false;
+}
+EXPORT_SYMBOL(blk_reinsert_req_sup);
+
static void add_acct_request(struct request_queue *q, struct request *rq,
int where)
{
diff --git a/block/elevator.c b/block/elevator.c
index a0ffdd9..2516ae2 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -553,6 +553,41 @@ void elv_requeue_request(struct request_queue *q, struct request *rq)
__elv_add_request(q, rq, ELEVATOR_INSERT_REQUEUE);
}
+/**
+ * elv_reinsert_request() - Insert a request back to the scheduler
+ * @q: request queue where request should be inserted
+ * @rq: request to be inserted
+ *
+ * This function returns the request back to the scheduler to be
+ * inserted as if it was never dispatched
+ *
+ * Return: 0 on success, error code on failure
+ */
+int elv_reinsert_request(struct request_queue *q, struct request *rq)
+{
+ int res;
+
+ if (!q->elevator->type->ops.elevator_reinsert_req_fn)
+ return -EPERM;
+
+ res = q->elevator->type->ops.elevator_reinsert_req_fn(q, rq);
+ if (!res) {
+ /*
+ * it already went through dequeue, we need to decrement the
+ * in_flight count again
+ */
+ if (blk_account_rq(rq)) {
+ q->in_flight[rq_is_sync(rq)]--;
+ if (rq->cmd_flags & REQ_SORTED)
+ elv_deactivate_rq(q, rq);
+ }
+ rq->cmd_flags &= ~REQ_STARTED;
+ q->nr_sorted++;
+ }
+
+ return res;
+}
+
void elv_drain_elevator(struct request_queue *q)
{
static int printed;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 2f91edb..7c6839b 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -732,6 +732,8 @@ extern struct request *blk_get_request(struct request_queue *, int, gfp_t);
extern struct request *blk_make_request(struct request_queue *, struct bio *,
gfp_t);
extern void blk_requeue_request(struct request_queue *, struct request *);
+extern int blk_reinsert_request(struct request_queue *q, struct request *rq);
+extern bool blk_reinsert_req_sup(struct request_queue *q);
extern void blk_add_request_payload(struct request *rq, struct page *page,
unsigned int len);
extern int blk_rq_check_limits(struct request_queue *q, struct request *rq);
diff --git a/include/linux/elevator.h b/include/linux/elevator.h
index acd0312..d703f94 100644
--- a/include/linux/elevator.h
+++ b/include/linux/elevator.h
@@ -23,6 +23,8 @@ typedef void (elevator_bio_merged_fn) (struct request_queue *,
typedef int (elevator_dispatch_fn) (struct request_queue *, int);
typedef void (elevator_add_req_fn) (struct request_queue *, struct request *);
+typedef int (elevator_reinsert_req_fn) (struct request_queue *,
+ struct request *);
typedef struct request *(elevator_request_list_fn) (struct request_queue *, struct request *);
typedef void (elevator_completed_req_fn) (struct request_queue *, struct request *);
typedef int (elevator_may_queue_fn) (struct request_queue *, int);
@@ -48,6 +50,8 @@ struct elevator_ops
elevator_dispatch_fn *elevator_dispatch_fn;
elevator_add_req_fn *elevator_add_req_fn;
+ elevator_reinsert_req_fn *elevator_reinsert_req_fn;
+
elevator_activate_req_fn *elevator_activate_req_fn;
elevator_deactivate_req_fn *elevator_deactivate_req_fn;
@@ -126,6 +130,7 @@ extern void elv_merged_request(struct request_queue *, struct request *, int);
extern void elv_bio_merged(struct request_queue *q, struct request *,
struct bio *);
extern void elv_requeue_request(struct request_queue *, struct request *);
+extern int elv_reinsert_request(struct request_queue *, struct request *);
extern struct request *elv_former_request(struct request_queue *, struct request *);
extern struct request *elv_latter_request(struct request_queue *, struct request *);
extern int elv_register_queue(struct request_queue *q);
--
1.7.6
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On Mon, Mar 25 2013, Tanya Brokhman wrote:
> From: Tatyana Brokhman <[email protected]>
>
> Add support for reinserting a dispatched request back to the
> scheduler's internal data structures.
> This capability is used by the device driver when it chooses to
> interrupt the current request transmission and execute another (more
> urgent) pending request. For example: interrupting long write in order
> to handle pending read. The device driver re-inserts the
> remaining write request back to the scheduler, to be rescheduled
> for transmission later on.
>
> Add API for verifying whether the current scheduler
> supports reinserting requests mechanism. If reinsert mechanism isn't
> supported by the scheduler, this code path will never be activated.
This is practically the exact same operation as a requeue. So why this
duplication? I also don't quite understand why an IO scheduler would
have to opt-in for this, seems like a pretty basic operation.
--
Jens Axboe
Hi Jens
>> Add support for reinserting a dispatched request back to the
>> scheduler's internal data structures.
>> This capability is used by the device driver when it chooses to
>> interrupt the current request transmission and execute another (more
>> urgent) pending request. For example: interrupting long write in order
>> to handle pending read. The device driver re-inserts the
>> remaining write request back to the scheduler, to be rescheduled
>> for transmission later on.
>>
>> Add API for verifying whether the current scheduler
>> supports reinserting requests mechanism. If reinsert mechanism isn't
>> supported by the scheduler, this code path will never be activated.
>
> This is practically the exact same operation as a requeue.
Not exactly. When you requeue request X it will be the next one to be
dispatched and handled by the device driver. When you reinsert a request,
you reinset it back to the I/O scheduler and not to the dispatch queue.
That means that this reinserted request will be rescheduled and its
possible that it wont be the next one to be dispatched since there might
be more urgent requests pending.
For example: an urgent request notification was sent to the device driver
that is currently transmitting a long packed WRITE command. The urgent
request pending to be served is a READ request. The device driver decides
to stop the packed WRITE request and handle the urgent READ. This is the
difference between requeue and reinsert:
- if we requeue the stopped packed WRITE, it will be immediately fetched
and transmitted again and the READ will be left pending till the packed
WRITE completes. In this case there was no point in stopping the packed
WRITE
- if we reinsert the stopped packed WRITE the next request to be
dispatched will be the urgent READ request (since READ is given priority
over WRITE) and this will reduce the READ latency greatly.
> So why this
> duplication? I also don't quite understand why an IO scheduler would
> have to opt-in for this, seems like a pretty basic operation.
I hope the above example addressed this as well. Please let me know if
this is not the case.
Thanks
Tanya Brokhman
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
On Wed, Mar 27 2013, [email protected] wrote:
> Hi Jens
>
> >> Add support for reinserting a dispatched request back to the
> >> scheduler's internal data structures.
> >> This capability is used by the device driver when it chooses to
> >> interrupt the current request transmission and execute another (more
> >> urgent) pending request. For example: interrupting long write in order
> >> to handle pending read. The device driver re-inserts the
> >> remaining write request back to the scheduler, to be rescheduled
> >> for transmission later on.
> >>
> >> Add API for verifying whether the current scheduler
> >> supports reinserting requests mechanism. If reinsert mechanism isn't
> >> supported by the scheduler, this code path will never be activated.
> >
> > This is practically the exact same operation as a requeue.
>
> Not exactly. When you requeue request X it will be the next one to be
> dispatched and handled by the device driver. When you reinsert a request,
> you reinset it back to the I/O scheduler and not to the dispatch queue.
> That means that this reinserted request will be rescheduled and its
> possible that it wont be the next one to be dispatched since there might
> be more urgent requests pending.
> For example: an urgent request notification was sent to the device driver
> that is currently transmitting a long packed WRITE command. The urgent
> request pending to be served is a READ request. The device driver decides
> to stop the packed WRITE request and handle the urgent READ. This is the
> difference between requeue and reinsert:
> - if we requeue the stopped packed WRITE, it will be immediately fetched
> and transmitted again and the READ will be left pending till the packed
> WRITE completes. In this case there was no point in stopping the packed
> WRITE
> - if we reinsert the stopped packed WRITE the next request to be
> dispatched will be the urgent READ request (since READ is given priority
> over WRITE) and this will reduce the READ latency greatly.
I said practically the same, not exactly the same! In any case, the
point is that you could reuse the exact same infrastructure for this,
instead of literally duplicating everything. Have some helper that does
the grunt of the work, pass in whether or not you want the existing
requeue event, or a reinsert event.
--
Jens Axboe
Hi Jens
>
> I said practically the same, not exactly the same! In any case, the
> point is that you could reuse the exact same infrastructure for this,
> instead of literally duplicating everything. Have some helper that does
> the grunt of the work, pass in whether or not you want the existing
> requeue event, or a reinsert event.
>
Thank you for the input. Will do and upload a new patch.
Thanks,
Tanya Brokhman
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation