Hi. Wu. I will update documentation as per your suggestion. Thank you.
2012/9/11, Fengguang Wu <fengguang...@intel.com>: > On Mon, Aug 27, 2012 at 12:01:41PM -0400, Namjae Jeon wrote: >> From: Namjae Jeon <namjae.j...@samsung.com> >> >> This commit adds dirty_background_time description in bdi sysfs >> documentation. >> >> Signed-off-by: Namjae Jeon <namjae.j...@samsung.com> >> Signed-off-by: Vivek Trivedi <t.vi...@samsung.com> >> --- >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
