When the scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in order to handle the urgent one. This is done
in order to reduce the latency of an urgent request. For example:
long WRITE may be sto
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
From: Jens Axboe
We have officially run out of flags in a 32-bit space. Extend it
to 64-bit even on 32-bit archs.
Signed-off-by: Jens Axboe
diff --git a/block/blk-core.c b/block/blk-core.c
index 93a18d1..cfa4dd3 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -174,9 +174,9 @@ void blk_
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 or
t for convenience.
Jens Axboe (1):
block: make rq->cmd_flags be 64-bit
Tanya Brokhman (3):
block: Add support for reinsert a dispatched req
block: Add API for URGENT request handling
block: Add URGENT request notification support to CFQ scheduler
block/blk-core.c | 89 ++
Hello Jeff
Thank you for your comments. Please see inline.
On 7/11/2013 9:41 PM, Jeff Moyer wrote:
Tanya Brokhman writes:
When the scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in
When the scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in order to handle the urgent one. This is done
in order to reduce the latency of an urgent request. For example:
long WRITE may be sto
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
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 or
From: Jens Axboe
We have officially run out of flags in a 32-bit space. Extend it
to 64-bit even on 32-bit archs.
Signed-off-by: Jens Axboe
diff --git a/block/blk-core.c b/block/blk-core.c
index 93a18d1..cfa4dd3 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -174,9 +174,9 @@ void blk_
t for convenience.
Jens Axboe (1):
block: make rq->cmd_flags be 64-bit
Tanya Brokhman (3):
block: Add support for reinsert a dispatched req
block: Add API for URGENT request handling
block: Add URGENT request notification support to CFQ scheduler
block/blk-core.c | 107
This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
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 or
From: Jens Axboe
We have officially run out of flags in a 32-bit space. Extend it
to 64-bit even on 32-bit archs.
Signed-off-by: Jens Axboe
diff --git a/block/blk-core.c b/block/blk-core.c
index 0852e5d..0256a5b 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -174,9 +174,9 @@ void blk_
422|
ROW|151.4| 41.07 | 51.5 |
This development depends on a patch introduced by Jens Axboe in
linux-block git tree which extends the req->cmd_flags field.
It's attached to this patch set for convenience.
Jens Axboe (1):
block: ma
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin
At the moment no new request flags can be added to enum rq_flag_bits
due to cmd_flags field size limitation. This commit adds a new filed to be used
as
an extensions to cmd_flags.
Signed-off-by: Tanya Brokhman
diff --git a/block/blk-core.c b/block/blk-core.c
index fe3683c..3a14987 100644
--- a
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 or
422|
ROW|151.4| 41.07 | 51.5 |
Tanya Brokhman (4):
block: Add support for reinsert a dispatched req
block: Extend cmd_flags in struct request
block: Add API for urgent request handling
block: Adding ROW scheduling algorithm
This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin
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 or
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
At the moment no new request flags can be added to enum rq_flag_bits
due to cmd_flags field size limitation. This commit adds a new filed to be used
as
an extensions to cmd_flags.
Signed-off-by: Tanya Brokhman
diff --git a/block/blk-core.c b/block/blk-core.c
index fe3683c..3a14987 100644
--- a
422|
ROW|151.4| 41.07 | 51.5 |
Tanya Brokhman (4):
block: Add support for reinsert a dispatched req
block: Extend cmd_flags in struct request
block: Add API for urgent request handling
block: Adding ROW scheduling algorithm
This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
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 or
is
decreased by ~66%. All measured for READ/WRITE coalition scenarios.
Tanya Brokhman (3):
block: Add support for reinsert a dispatched req
block: Add API for urgent request handling
block: Adding ROW scheduling algorithm
Documentation/block/row-iosched.txt | 134 +
block/Kconfig.iosched
Hi Tejun
Thank you for the detailed explanation!
Best Regards
Tanya Brokhman
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
On 4/9/2013 10:03 PM, Tejun Heo wrote:
Hey,
On Mon, Apr 08, 2013 at 07:19:19AM
ompleted after the
FLUSH. But perhaps there is a correct way to move the implementation of
"ordering around the flush" to the block layer? Not that it would work
better, it just feels that logically - block layer is the place to do it
at.
What do you think?
Best Regards,
Tanya Brokhm
. Is
this indeed the case? I didn't find any documentation on it on the web.
Thanks,
Tanya Brokhman
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "un
On 3/25/2013 2:40 PM, Jens Axboe wrote:
On Mon, Mar 25 2013, Tanya Brokhman wrote:
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
sched
nt 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
--
To unsubscribe fro
This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
blo
From: Tatyana Brokhman
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: inte
is
decreased by ~66%. All measured for READ/WRITE coalition scenarios.
Tanya Brokhman (2):
block: Add API for urgent request handling
block: Adding ROW scheduling algorithm
Tatyana Brokhman (1):
block: Add support for reinsert a dispatched req
Documentation/block/row-iosched.txt | 134 +++
This patch add support for handling urgent requests.
ROW queue can be marked as "urgent". If an urgent queue was
un-served in a previous dispatch cycle and a request was added
to it - it will trigger issuing urgent request to the device driver.
Signed-off-by: Tatyana Brokhman
diff --git a/block/
Add support for reinserting already dispatched request back to the
schedulers internal data structures.
The request will be reinserted back to the queue (head) it was
dispatched from as if it was never dispatched.
Signed-off-by: Tatyana Brokhman
---
v3: Update error handling when row queue is not
This patch set add support for handling urgent requests by the
ROW algorith. It depends on 2 previosly uploaded patch sets:
1. ROW scheduling Algorithm
2. Adding support for urgent requests handling (in block layer)
Tanya Brokhman (2):
row: Adding support for reinsert already dispatched req
This patch adds the implementation of a new scheduling algorithm - ROW.
The policy of this algorithm is to prioritize READ requests over WRITE
as much as possible without starving the WRITE requests.
The requests are kept in queues according to their priority. The dispatch
is done in a Round Robin
From: Tatyana Brokhman
ROW is a new scheduling algorithm. Similar to the existing scheduling
algorithms it should be compiled to the kernel statically giving the user
the ability to switch to it without kernel recompilation.
Signed-off-by: Tatyana Brokhman
diff --git a/block/Kconfig.iosched b/
From: Tatyana Brokhman
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Urgent request notification is passed to the underlying
block device driver (eMMC for example). Block device driver may deci
From: Tatyana Brokhman
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: inte
This patch set adds support in block & elevator layers for handling
urgent requests.
In order to decrease the latency of a prioritized request (such as READ
requests) we might want to stop the transmission of a current "low
priority" request in order to handle the "high priority" one. The
urgency o
mail
etc. And of course I tried lmdd both ways.
>
> Kind regards
> Ulf Hansson
>
Thanks,
Tanya Brokhman
---
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the li
y specific test scenario you want me to
run.
(Sorry it took me some time to get back to you. It's holiday season in
Israel)
Thanks,
Tanya Brokhman
---
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
> -Origi
Hi Ulf
>
> Nope, this is the only one needed.
> Thanks a lot for helping out!
>
Np.
I understand this is a bit urgent. Will do my best to speed it up...
Thanks,
Tanya Brokhman
---
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, h
nt,
> as some may be early prototypes.
>
> What exactly do you need tested?
>
> Arnd
> --
Hi
We have eMMC4.5 board and can help with the testing.
Are there other patches besides this one I should take in?
Thanks,
Tanya Brokhman
---
QUALCOMM ISRAEL, on behalf of Qual
.
We have a patch that also measures latency and we saw that read latency was
also improved greatly when using ROW.
Thanks,
Tanya Brokhman
---
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscr
uld you please give me the exact iozone command you used? I'll replay it on
my setup.
Thanks,
Tanya Brokhman
---
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send th
n our Android based device. I don't know what numbers will
ROW produce if you run it on a PC because as I mentioned, ROW was developed
to run on mobile devices.
As I mentioned, the test I performed was parallel READ and WRITE using lmdd.
I'm not sure I understand what info is missing in order
54 matches
Mail list logo
