Re: [PATCH] Documentation: cfq-iosched: update documentation helpfor cfq tunnables

[Rob Landley]

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 <namjae.jeon@xxxxxxxxxxx>
>
> 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 <namjae.jeon@xxxxxxxxxxx>
> Signed-off-by: Amit Sahrawat <a.sahrawat@xxxxxxxxxxx>
> ---
>  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--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/