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 order to handle the urgent one. This is done
> in order to reduce the latency of an urgent request. F
On Thu, Jul 11, 2013 at 6:31 PM, Tanya Brokhman wrote:
> 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
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
In order to decrease the latency of a prioritized request (such as READ
requests) the device driver might decide to stop the transmission of a
current "low priority" request in order to handle the "high priority" one.
The urgency of the request is decided by the block layer I/O scheduler.
When the
On 7/10/2013 7:01 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
Add runtime PM helpers to suspend/resume UFS controller at runtime.
Enable runtime PM by default for pci and platform drivers as the
initialized hardware can suspend if it is not used after bootup.
Signe
On 7/10/2013 7:01 PM, Seungwon Jeon wrote:
I'm not sure that BKOPS with runtime-pm associates.
Do you think it's helpful for power management?
How about hibernation scheme for runtime-pm?
I'm testing and I can introduce soon.
Well, I am thinking on following approach when we introduce
power man
On 7/10/2013 6:58 PM, Seungwon Jeon wrote:
> On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
>> As part of device initialization sequence, sending NOP OUT UPIU and
>> waiting for NOP IN UPIU response is mandatory. This confirms that the
>> device UFS Transport (UTP) layer is functional and the hos
10 matches
Mail list logo
