Re: setitimer expire too early (Kernel 2.4)

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Sun, Jul 03, 2005 at 08:56:59AM -0300, Marcelo Tosatti wrote:
> On Fri, Jul 01, 2005 at 02:14:42PM -0700, George Anzinger wrote:
> > Marcelo Tosatti wrote:
> > >Hi Olivier,
> > >
> > >On Fri, Jul 01, 2005 at 07:52:12PM +0200, Olivier Croquette wrote:
> > >
> > >>Andrew Morton wrote:
> > >>
> > >>>>Linus, Andrew, do you consider this critical enough to be merged to 
> > >>>>the v2.4 tree?
> > >>>
> > >>>
> > >>>No.  I'd expect this would hurt more people than it would benefit.
> > >>
> > >>
> > >>Probably.
> > >>Does that mean that the kernel 2.4 will keep this bug for ever?
> > >
> > >
> > >Probably, yes. I've never heard such complaints before your message.
> > >
> > >The right way to do it seems something else BTW:
> > >
> > >quoting Nish Aravamudan (http://lkml.org/lkml/2005/4/29/240):
> > >
> > >Your patch is the only way to guarantee no early timeouts, as far as I 
> > >know.
> > >
> > >Really, what you want is:
> > >
> > >on adding timers, take the ceiling of the interval into which it could be 
> > >added
> > >on expiring timers, take the floor
> > >
> > >This combination guarantees no timers go off early (and takes away
> > >many of these corner cases). I do exactly this in my patch, btw.
> > 
> > IMNSHO that is just another way of saying "add 1 to the jiffie count" which 
> > is what the proposed patch does.
> 
> Hi George, 
> 
> OK - I'll write a test case to confirm there are no such longer delay 
> regressions as Paulo suggests.  
> 
> Thanks for your advice.

Hi folks,

There is indeed a systematic increase of +20ms when adding "+1" to the expiration
interval. 

Since no one has noticed this before I continue to wonder if its worth adding this 
to v2.4 at this point in time.