From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 2/2] UBIFS: start using hrtimers Date: Fri, 29 May 2009 15:32:37 +0200 Message-ID: <1243603957.23657.217.camel@twins> References: <20090529150929.8912.33879.sendpatchset@localhost.localdomain> <20090529150944.8912.95076.sendpatchset@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , linux-fsdevel@vger.kernel.org, Steven Rostedt , Arjan van de Ven To: Artem Bityutskiy Return-path: In-Reply-To: <20090529150944.8912.95076.sendpatchset@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2009-05-29 at 18:09 +0300, Artem Bityutskiy wrote: > From: Artem Bityutskiy > Subject: [PATCH 2/2] UBIFS: start using hrtimers > > UBIFS uses timers for write-buffer write-back. It is not > crucial for us to write-back exactly on time. We are fine > to write-back a little earlier or later. And this means > we may optimize UBIFS timer so that it could be groped > with a close timer event, so that the CPU would not be > waken up just to do the write back. This is optimization > to lessen power consumption, which is important in > embedded devices UBIFS is used for. > > hrtimers have a nice feature: they are effectively range > timers, and we may defind the soft and hard limits for > it. Standard timers do not have these feature. They may > only be made deferrable, but this means there is effectively > no hard limit. So, we will better use hrtimers. > > Signed-off-by: Artem Bityutskiy > --- Seems sane enough from a hrtimer POV, but isn't this already functionality that the VFS/pdflush provide?