Re: [PATCH 2/2] Documentation: add description of dirty_background_time

[Namjae Jeon]

Hi. Wu.

I will update documentation as per your suggestion.
Thank you.

2012/9/11, Fengguang Wu <fengguang.wu@xxxxxxxxx>:
> On Mon, Aug 27, 2012 at 12:01:41PM -0400, Namjae Jeon wrote:
>> From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
>>
>> This commit adds dirty_background_time description in bdi sysfs
>> documentation.
>>
>> Signed-off-by: Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
>> Signed-off-by: Vivek Trivedi <t.vivek@xxxxxxxxxxx>
>> ---
>>  Documentation/ABI/testing/sysfs-class-bdi |   13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-bdi
>> b/Documentation/ABI/testing/sysfs-class-bdi
>> index 5f50097..018e26a 100644
>> --- a/Documentation/ABI/testing/sysfs-class-bdi
>> +++ b/Documentation/ABI/testing/sysfs-class-bdi
>> @@ -48,3 +48,16 @@ max_ratio (read-write)
>>  	most of the write-back cache.  For example in case of an NFS
>>  	mount that is prone to get stuck, or a FUSE mount which cannot
>>  	be trusted to play fair.
>> +
>> +dirty_background_time (read-write)
>> +
>> +	It is used to start early writeback of given bdi once bdi dirty
>> +	data exceeds product of average write bandwidth and
>> +	dirty_background_time.
>
> It may be worth to note that it works _in parallel with_ the global
> background writeback threshold rather than replacing it.
>
>> It is mainly useful for tuning writeback
>> +	speed at 'NFS Server' so that NFS client could see better write speed.
>
> Hopefully more clear:
>
> A good use case is setting it to around 100 (1 second) in the NFS
> server for improving NFS write performance. Note that it's not
> recommended to set it to a too small value, which might lead to
> small IO size. Setting it to 0 disables the feature.
>
>> +	However, sometimes it may not match user expectations as it is based
>> +	on bdi write bandwidth estimation.
>
> The users should not expect this threshold to work accurately.
>
>> Write bandwidth estimation is a
>> +	best effort to estimate bdi write speed bandwidth. But it can be
>> +	wildly wrong in certain situations.
>
> such as sudden change of workload (including the workload startup stage),
> or if there are no heavy writes since boot, in which case there is no
> reasonable estimation yet.
>
>> +	dirty_background_time is expressed in msec.
>
> That can be eliminated if changing to dirty_background_centisecs.
>
> Thanks,
> Fengguang
>
--
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/