Hi Hu,
On 12/29/2014 5:14 AM, hujianyang wrote:
On 2014/11/3 21:58, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
The R/O block driver messages
han they
become hard errors, and you are done.
We decided to drop this solution and stay with "force scrub" all PEBs
from time to time, triggered from userspace.
Thank you all for your inputs and comments! It was very helpful in
coming to this decision.
Thanks,
Tanya Brokhman
--
On 11/12/2014 1:55 PM, Artem Bityutskiy wrote:
On Tue, 2014-11-11 at 22:36 +0200, Tanya Brokhman wrote:
Unfortunately none. This is done for a new device that we received just
now. The development was done on a virtual machine with nandsim. Testing
was more of stability and regression
OK. So
Hi Artem,
Hope I didn't drop any ccs this time... Sorry about that. Not on purpose.
On 11/7/2014 10:58 AM, Artem Bityutskiy wrote:
On Thu, 2014-11-06 at 14:16 +0200, Tanya Brokhman wrote:
What I'm trying to say - it
may be too late and you may lose data here. "preferred to prev
On 11/10/2014 7:57 PM, Joe Perches wrote:
On Mon, 2014-11-10 at 18:37 +0100, Richard Weinberger wrote:
Am 03.11.2014 um 14:58 schrieb Tanya Brokhman:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to
On 11/10/2014 2:18 PM, Artem Bityutskiy wrote:
On Sun, 2014-11-09 at 13:06 +0200, Tanya Brokhman wrote:
/* Normal UBI messages */
#define ubi_msg(ubi, fmt, ...) pr_notice("UBI-%d: %s:" fmt "\n", \
-ubi->ubi_num,
Some cosmetic fixes to the patch "UBI: Extend UBI layer debug/messaging
capabilities".
Signed-off-by: Tanya Brokhman
---
Changes from original patch:
- Added ptr verification @ ubi_err/ubi_msg/ubi_warn
Removed extra printing of ubi number
Removed new messages.
On 11/7/2014 12:08 PM, hujianyang wrote:
On 2014/11/5 23:35, Artem Bityutskiy wrote:
On Mon, 2014-11-03 at 15:58 +0200, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi
On 11/3/2014 5:08 AM, hujianyang wrote:
Hi Tanya,
On 2014/11/3 1:14, Tanya Brokhman wrote:
This patch add 'struct ubi_device *' for 3 functions. We can get 'ubi_device'
from
'ubi_volume'. So I think it's because when we call these functions, the &#x
On 11/2/2014 7:02 PM, Richard Weinberger wrote:
Am 02.11.2014 um 15:12 schrieb Tanya Brokhman:
Back to topic.
Storing the read-counters into fastmap also not a good idea because the fastmap
can get lost completely (by design).
yes,I'm aware of that. We have a default value for that case
try_to_freeze())
continue;
Here are two new adding messages. Maybe a separate patch is better? Just a
suggestion.
Done.
@@ -1415,8 +1418,9 @@ int ubi_self_check_all_ff(struct ubi_device *ubi, int
pnum, int offset, int len)
return 0;
fail:
- ubi_er
On 11/2/2014 3:54 PM, Richard Weinberger wrote:
Am 02.11.2014 um 14:23 schrieb Tanya Brokhman:
Okay, read-disturb will only happen if you read blocks *very* often. Do you
have numbers, datasheets, etc...?
Yes. In 0001-mtd-ubi-Read-disturb-infrastructure.patch you'll find:
#d
On 10/31/2014 5:39 PM, Richard Weinberger wrote:
Am 31.10.2014 um 16:34 schrieb Richard Weinberger:
Hi Tanya,
Am 31.10.2014 um 14:12 schrieb Tanya Brokhman:
Hi Richard
On 10/29/2014 2:00 PM, Richard Weinberger wrote:
Tanya,
Am 29.10.2014 um 12:03 schrieb Tanya Brokhman:
I'll t
On 10/31/2014 5:34 PM, Richard Weinberger wrote:
Hi Tanya,
Am 31.10.2014 um 14:12 schrieb Tanya Brokhman:
Hi Richard
On 10/29/2014 2:00 PM, Richard Weinberger wrote:
Tanya,
Am 29.10.2014 um 12:03 schrieb Tanya Brokhman:
I'll try to address all you comments in one place.
You're
Hi Richard
On 10/29/2014 2:00 PM, Richard Weinberger wrote:
Tanya,
Am 29.10.2014 um 12:03 schrieb Tanya Brokhman:
I'll try to address all you comments in one place.
You're right that the read counters don't have to be exact but they do have to
reflect the real state.
But it
On 10/30/2014 10:40 AM, Artem Bityutskiy wrote:
Yeah, lets' correct this too.
Thanks for ferview Hujianyang!
Tanya, would you send a follow-up patch these?
Yes, sure.
Sorry, was pulled into some urgent stuff. Will post a new patch early
next week.
Artem.
Thanks,
Tanya Bro
Hi Richard
On 10/27/2014 10:56 AM, Richard Weinberger wrote:
Tanya,
Am 27.10.2014 um 09:41 schrieb Tanya Brokhman:
So, your patch addresses the following issue:
We need to re-read a PEB after a specific time (to detect bit rot) or after N
reads (to detect read disturb issues).
Is this
On 10/26/2014 10:39 PM, Richard Weinberger wrote:
Am 26.10.2014 um 14:49 schrieb Tanya Brokhman:
One of the limitations of the NAND devices is the method used to read
NAND flash memory may cause bit-flips on the surrounding cells and result
in uncorrectable ECC errors. This is known as the read
Make the in_wl_tree function public to be used outside of wl.c.
Rename it to ubi_in_wl_tree.
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/ubi.h | 1 +
drivers/mtd/ubi/wl.c | 18 +-
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/ubi/ubi.h b
ubi->scrub
list.
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/eba.c | 7 ++-
drivers/mtd/ubi/wl.c | 56 +--
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index 0e116
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/build.c | 32 +--
drivers/mtd/ubi/ubi.h | 3 +
drivers/mtd/ubi/wl.c| 143 +++-
3 files changed, 171 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi
.
Signed-off-by: Dolev Raviv
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/attach.c | 137 +++---
drivers/mtd/ubi/debug.c | 11
drivers/mtd/ubi/fastmap.c | 118 ++-
drivers/mtd/ubi/io.c | 28
unchanged and resent just for reference. Still
working on comments from Richard on fastmap layout.
All comments that were made for V1 will be addressed in the next patch
set. This version is just for the addition of the documentation file.
Tanya Brokhman (5):
mtd: ubi: Read disturb
statistics
Signed-off-by: Tanya Brokhman
---
Changes from V1:
- Documentation file was added
Documentation/mtd/ubi/ubi-read-disturb.txt | 145 +
drivers/mtd/ubi/build.c| 57
drivers/mtd/ubi/fastmap.c | 14 ++-
drivers
On 10/21/2014 10:56 AM, Artem Bityutskiy wrote:
On Mon, 2014-10-20 at 19:57 +0300, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
The R/O block
em insists on it.
Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-ms
On 10/13/2014 6:59 PM, Artem Bityutskiy wrote:
On Mon, 2014-10-13 at 18:37 +0300, Artem Bityutskiy wrote:
On Mon, 2014-10-06 at 14:01 +0300, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add
On 10/2/2014 4:36 PM, Richard Weinberger wrote:
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
Hi Richard,
Sorry it took me some time to answer, got per-occupied with some urgent staff.
On 9/28/2014 1:54 PM, Richard Weinberger wrote:
Am 28.09.2014 12:46, schrieb Tanya Brokhman:
On 9/28/2014
On 10/2/2014 4:24 PM, Richard Weinberger wrote:
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
Consider the case where you have a board with a fastmap enabled bootloader and
a Linux OS.
The bootloader does a fastmap attach and boots the kernel from UBI and the
kernel it self has the rootfs
on
Hi Richard,
Sorry it took me some time to answer, got per-occupied with some urgent
staff.
On 9/28/2014 1:54 PM, Richard Weinberger wrote:
Am 28.09.2014 12:46, schrieb Tanya Brokhman:
On 9/28/2014 11:54 AM, Richard Weinberger wrote:
Am 28.09.2014 10:48, schrieb Tanya Brokhman:
@@ -424,6
On 9/28/2014 3:01 PM, Artem Bityutskiy wrote:
On Sun, 2014-09-28 at 09:36 +0300, Tanya Brokhman wrote:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
Hi, the goal looks
On 9/29/2014 3:37 PM, Richard Weinberger wrote:
Am 29.09.2014 14:32, schrieb Kiran Padwal:
On Monday 29 September 2014 05:31 PM, Richard Weinberger wrote:
Am 29.09.2014 12:50, schrieb Kiran Padwal:
Hi Tanya,
On Sunday 28 September 2014 12:06 PM, Tanya Brokhman wrote:
If there is more then
On 9/28/2014 3:11 PM, Artem Bityutskiy wrote:
On Sun, 2014-09-28 at 09:37 +0300, Tanya Brokhman wrote:
The need for performing read disturb is determined according to new
statistics collected per eraseblock:
- read counter: incremented at each read operation
reset at each erase
On 9/28/2014 11:54 AM, Richard Weinberger wrote:
Am 28.09.2014 10:48, schrieb Tanya Brokhman:
@@ -424,6 +440,8 @@ struct ubi_fm_sb {
__be32 used_blocks;
__be32 block_loc[UBI_FM_MAX_BLOCKS];
__be32 block_ec[UBI_FM_MAX_BLOCKS];
+__be32 block_rc[UBI_FM_MAX_BLOCKS
On 9/28/2014 11:42 AM, Richard Weinberger wrote:
Tanya,
On Sun, Sep 28, 2014 at 8:38 AM, Tanya Brokhman wrote:
A given eraseblock can be read many times or not at all.
We do not have the account of such eraseblocks that have
not been accessed since a pre-defined threshold interval.
By means
Hi Richard
On 9/28/2014 11:18 AM, Richard Weinberger wrote:
index 0431b46..5399aa2 100644
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -1,5 +1,7 @@
/*
* Copyright (c) 2012 Linutronix GmbH
+ * Copyright (c) 2014, Linux Foundation. All rights reserved.
+ *
Diffstat s
On 9/28/2014 11:01 AM, Richard Weinberger wrote:
Tanya,
Am 28.09.2014 08:36, schrieb Tanya Brokhman:
If there is more then one UBI device mounted, there is no way to
distinguish between messages from different UBI devices.
Add device number to all ubi layer message types.
Signed-off-by
A given eraseblock can be read many times or not at all.
We do not have the account of such eraseblocks that have
not been accessed since a pre-defined threshold interval.
By means of scanning the entire flash device it is possible to identify
all such eraseblocks.
Add a sysfs entry to force scan
scrubbing is added to the ubi->scrub
list.
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/eba.c | 7 ++-
drivers/mtd/ubi/wl.c | 56 +--
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/
From: Tatyana Brokhman
Make the in_wl_tree function public to be used outside of wl.c.
Rename it to ubi_in_wl_tree.
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/ubi.h | 1 +
drivers/mtd/ubi/wl.c | 18 +-
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a
statistics
Signed-off-by: Tanya Brokhman
---
drivers/mtd/ubi/build.c | 57 +
drivers/mtd/ubi/fastmap.c | 14 +++
drivers/mtd/ubi/ubi-media.h | 32 ++---
drivers/mtd/ubi/ubi.h | 34 +++
drivers/mtd
From: Tatyana Brokhman
Fill in eraseblock statistics needed for read disturb decision making:
1. read counter: incremented at each read operation
reset at each erase operation
Saved only as part of the meta data in RAM
On attach: if fastmap data is missing a default value
can no longer be ignored
otherwise there will be data loss over time.
The following patch set implements handling of Read-disturb and Data
retention by the UBI layer.
Tanya Brokhman (2):
mtd: ubi: Read disturb infrastructure
mtd: ubi: Add sysfs entry to force all pebs' scan
Tatyana Bro
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
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_
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
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 | 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 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
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
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
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
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
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
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/
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
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
7;t encounter the bug you
observed but I'll look into it. Thanks again.
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 "unsubscrib
.
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 thi
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
the only reason we need this patch at the moment.
But in any case, due to the comments we got on it from Greg/Alan/Felipe this
patch is rewritten at the moment by its original author Amit Blay
(ab...@codeaurora.org). He'll post a new version of it once he's done.
Thanks,
Tanya Bro
>
> One sec! I just found out that I was running checkpatch.pl from a wrong
> location. There is a checkpatch warning. I'll send you the fix in a few
> minutes.
> Sorry.
>
Done! Please pick up "[PATCH v2] usb: gadget: Compilation warning fix".
Sorry for the tr
tch
>
> Nope, you can't, I need just a single patch that resolves this. I'll
> queue up the patch you just sent, thanks.
>
One sec! I just found out that I was running checkpatch.pl from a wrong
location. There is a checkpatch warning. I'll send you the fix in a fe
ready merged the patch that caused the compilation
warning into his tree so perhaps you can't merge the fix into the original
patch and need to post the fix as a different patch
Thanks,
Tanya Brokhman
---
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Inn
it
already and I missed it again :) ?
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 the line "unsubscribe linux-arm-msm" in
>
> I have already fixed this one myself ;-)
>
Oh, ok :) Thank you!
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
ally good."
So, right now I'll leave it in dummy_hcd if it's ok with you.
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
ework
>
> This patch didn't reach linux-usb, maybe due to its size.
>
> WBR, Sergei
Hmm... I wasn't aware there was a size limitation... I'll try to split it up
and resend.
Thanks,
Tanya Brokhman
---
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The
ll on this one? Do you think it can be
merged or you prefer not change anything? I personally think the code looks
nicer using min_t instead of min with casting but that's just my opinion and
of course there are arguments against this patch.
Thanks,
Tanya Brokhman
---
Sent by an consultant
1 - 100 of 165 matches
Mail list logo
