On Mon 07-05-12 17:21:07, Peter Zijlstra wrote: > On Mon, 2012-05-07 at 22:47 +0800, Fengguang Wu wrote: > > On Fri, May 04, 2012 at 12:39:20AM +0200, Jan Kara wrote: > > > Convert calculations of proportion of writeback each bdi does to new flexible > > > proportion code. That allows us to use aging period of fixed wallclock time > > > which gives better proportion estimates given the hugely varying throughput of > > > different devices. > > > > > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > > --- > > > include/linux/backing-dev.h | 6 ++-- > > > mm/backing-dev.c | 5 +-- > > > mm/page-writeback.c | 80 ++++++++++++++++++++---------------------- > > > 3 files changed, 43 insertions(+), 48 deletions(-) > > > > > +static void vm_completions_period(struct work_struct *work); > > > +/* Work for aging of vm_completions */ > > > +static DECLARE_DEFERRED_WORK(vm_completions_period_work, vm_completions_period); > > > > > + > > > +static void vm_completions_period(struct work_struct *work) > > > +{ > > > + fprop_new_period(&vm_completions); > > > + schedule_delayed_work(&vm_completions_period_work, > > > + VM_COMPLETIONS_PERIOD_LEN); > > > +} > > > + > > > > Is it possible to optimize away the periodic work when there are no > > disk writes? > > That should really be a timer, nothing in there requires scheduling so > the entire addition of the workqueue muck is pure overhead. > > You could keep a second period counter that tracks the last observed > period and whenever the period and last_observed_period are further > apart than BITS_PER_LONG you can stop the timer. > > You'll have to restart it when updating last_observed_period. Good points. I'll improve this in the next version. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>