From: Namjae Jeon <[email protected]>
Add the documentation text for latency, target_latency & group_idle
tunnable parameters in the block/cfq-iosched.txt.
Also fix few typo(spelling) mistakes.
Signed-off-by: Namjae Jeon <[email protected]>
Signed-off-by: Amit Sahrawat <[email protected]>
---
Documentation/block/cfq-iosched.txt | 47 ++++++++++++++++++++++++++++++++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt
index a5eb7d1..4d02bca 100644
--- a/Documentation/block/cfq-iosched.txt
+++ b/Documentation/block/cfq-iosched.txt
@@ -5,7 +5,7 @@ The main aim of CFQ scheduler is to provide a fair allocation of the disk
I/O bandwidth for all the processes which requests an I/O operation.
CFQ maintains the per process queue for the processes which request I/O
-operation(syncronous requests). In case of asynchronous requests, all the
+operation(synchronous requests). In case of asynchronous requests, all the
requests from all the processes are batched together according to their
process's I/O priority.
@@ -66,6 +66,47 @@ This parameter is used to set the timeout of synchronous requests. Default
value of this is 124ms. In case to favor synchronous requests over asynchronous
one, this value should be decreased relative to fifo_expire_async.
+group_idle
+-----------
+This parameter forces idling at the CFQ group level instead of CFQ
+queue level. This is introduced after after a bottleneck was observed
+in higher end storage due to idle on sequential queuee and allow dispatch
+from a single queue. The idea with this parameter is that it be be run with
+slice_idle=0 and group_idle=8, so that idling does not happen on individual
+queues in the group but happens overall on the group and still keep the IO
+controller working.
+Not idling on individual queues in the group will dispatch requests from
+multiple queues in the group at the same time and achieve higher throughput
+on higher end storage.
+
+Default value for this parameter is 8ms.
+
+latency
+-------
+This parameter is used to enable/disable the latency mode of the CFQ
+scheduler. So if latency mode (called low_latency) is enabled, then CFQ tries
+to recompute the slice time for each process based on the target_latency set
+for the system. This favors the fairness over throughput. Disabling low
+latency (setting it to 0) ignores target latency, allowing each process in the
+system to get a full time slice.
+
+By default low latency mode is enabled.
+
+target_latency
+--------------
+This parameter is used to calculate the time slice for a process if cfq's
+latency mode is enabled. It will ensure that sync requests have an estimated
+latency. But sometime if sequential workload is more (e.g. sequential read),
+then to meet the latency constraints, throughput may decrease because of less
+time for each process to issue I/O request before the cfq queue is switched.
+
+Though this can be overcome by disabling the latency_mode, but it may increase
+the read latency for some applications. So, this parameter allows for changing
+target_latency through sysfs interface which can provide the balanced
+throughput and read latency.
+
+Default value for target_latency is 300ms.
+
slice_async
-----------
This parameter is same as of slice_sync but for asynchronous queue. The
@@ -98,8 +139,8 @@ in the device exceeds this parameter. This parameter is used for synchronous
request.
In case of storage with several disk, this setting can limit the parallel
-processing of request. Therefore, increasing the value can imporve the
-performace although this can cause the latency of some I/O to increase due
+processing of request. Therefore, increasing the value can improve the
+performance although this can cause the latency of some I/O to increase due
to more number of requests.
CFQ Group scheduling
--
1.7.9.5
On Sun, Mar 31 2013, Namjae Jeon wrote:
> From: Namjae Jeon <[email protected]>
>
> Add the documentation text for latency, target_latency & group_idle
> tunnable parameters in the block/cfq-iosched.txt.
> Also fix few typo(spelling) mistakes.
Thanks, merged with various fixups to the language. You can see the end-result
here:
http://git.kernel.dk/?p=linux-block.git;a=commit;h=fdc6fdc52e4630f5020281ce5450be7cc1887de2
--
Jens Axboe
2013/4/9 Jens Axboe <[email protected]>:
> On Sun, Mar 31 2013, Namjae Jeon wrote:
>> From: Namjae Jeon <[email protected]>
>>
>> Add the documentation text for latency, target_latency & group_idle
>> tunnable parameters in the block/cfq-iosched.txt.
>> Also fix few typo(spelling) mistakes.
>
> Thanks, merged with various fixups to the language. You can see the end-result
> here:
Thanks Jens !. I checked.
>
> http://git.kernel.dk/?p=linux-block.git;a=commit;h=fdc6fdc52e4630f5020281ce5450be7cc1887de2
>
> --
> Jens Axboe
>
Cleaning out "look at this" directory, I don't see this applied
upstream but it may already be in Jens' tree. (That's the tree it
should go in through...)
On 03/30/2013 09:55:04 PM, Namjae Jeon wrote:
> From: Namjae Jeon <[email protected]>
>
> Add the documentation text for latency, target_latency & group_idle
> tunnable parameters in the block/cfq-iosched.txt.
> Also fix few typo(spelling) mistakes.
>
> Signed-off-by: Namjae Jeon <[email protected]>
> Signed-off-by: Amit Sahrawat <[email protected]>
> ---
> Documentation/block/cfq-iosched.txt | 47
> ++++++++++++++++++++++++++++++++---
> 1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/block/cfq-iosched.txt
> b/Documentation/block/cfq-iosched.txt
> index a5eb7d1..4d02bca 100644
> --- a/Documentation/block/cfq-iosched.txt
> +++ b/Documentation/block/cfq-iosched.txt
> @@ -5,7 +5,7 @@ The main aim of CFQ scheduler is to provide a fair
> allocation of the disk
> I/O bandwidth for all the processes which requests an I/O operation.
>
> CFQ maintains the per process queue for the processes which request
> I/O
> -operation(syncronous requests). In case of asynchronous requests,
> all the
> +operation(synchronous requests). In case of asynchronous requests,
> all the
> requests from all the processes are batched together according to
> their
> process's I/O priority.
>
> @@ -66,6 +66,47 @@ This parameter is used to set the timeout of
> synchronous requests. Default
> value of this is 124ms. In case to favor synchronous requests over
> asynchronous
> one, this value should be decreased relative to fifo_expire_async.
>
> +group_idle
> +-----------
> +This parameter forces idling at the CFQ group level instead of CFQ
You don't need to say "this parameter", you can just start with "Force
idling at..."
> +queue level. This is introduced after after a bottleneck was observed
> +in higher end storage due to idle on sequential queuee and allow
> dispatch
queuee
> +from a single queue. The idea with this parameter is that it be be
> run with
> +slice_idle=0 and group_idle=8, so that idling does not happen on
> individual
> +queues in the group but happens overall on the group and still keep
> the IO
> +controller working.
> +Not idling on individual queues in the group will dispatch requests
> from
> +multiple queues in the group at the same time and achieve higher
> throughput
> +on higher end storage.
> +
> +Default value for this parameter is 8ms.
> +
> +latency
> +-------
> +This parameter is used to enable/disable the latency mode of the CFQ
"Enable/disable the latency mode..."
> +scheduler. So if latency mode (called low_latency) is enabled, then
> CFQ tries
> +to recompute the slice time for each process based on the
> target_latency set
> +for the system. This favors the fairness over throughput. Disabling
> low
> +latency (setting it to 0) ignores target latency, allowing each
> process in the
> +system to get a full time slice.
> +
> +By default low latency mode is enabled.
Why are latency and target_latency separate parameters? (0 already
disables it... the logical thing to do...?)
I.E. why does this knob even exist separate from target_latency?
> +target_latency
> +--------------
> +This parameter is used to calculate the time slice for a process if
> cfq's
> +latency mode is enabled. It will ensure that sync requests have an
> estimated
> +latency. But sometime if sequential workload is more (e.g.
> sequential read),
> +then to meet the latency constraints, throughput may decrease
> because of less
> +time for each process to issue I/O request before the cfq queue is
> switched.
> +
> +Though this can be overcome by disabling the latency_mode, but it
> may increase
> +the read latency for some applications. So, this parameter allows
> for changing
> +target_latency through sysfs interface which can provide the balanced
> +throughput and read latency.
> +
> +Default value for target_latency is 300ms.
Sorry, I try not to rewrite, but this whole section can just be:
Cap outstanding I/O requests to this many miliseconds (default 300),
ensuring sync requests have an estimated latency. Lowering this may
decrease throughput on sequential workloads by switching queues more
often (interleaving other I/O).
(And it could ahve been called target_latency_ms to be
self-documenting. Oh well.)
Rob-
On Sat, Apr 13 2013, Rob Landley wrote:
> Cleaning out "look at this" directory, I don't see this applied upstream but
> it may already be in Jens' tree. (That's the tree it should go in
> through...)
It's already included, see:
http://git.kernel.dk/?p=linux-block.git;a=commit;h=fdc6fdc52e4630f5020281ce5450be7cc1887de2
I changed some of the wording. But since this is your forte, please do
send any incremental patches against what is already in there.
--
Jens Axboe