Re: setitimer expire too early (Kernel 2.4)

Re: setitimer expire too early (Kernel 2.4)

[Marcelo Tosatti]

On Thu, Jun 30, 2005 at 09:14:50PM +0200, Olivier Croquette wrote:
> 
> I am refering to this bug:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=4569
> 
> A thread led to a patch from Paulo:
> 
> http://kerneltrap.org/mailarchive/1/message/59454/flat
> 
> This patch has been included in the kernel 2.6.12.
> 
> 1. How can I easily check if the patch is planned for include in the 2.4?
> 
> 2. I downloaded the full 2.4.31 source code. The patch appears not to be 
> included. Where/Who should I signal that?

And what about the side effects:
This however will produce pathological cases, like having a idle system
being requested 1 ms timeouts will give systematically 2 ms timeouts,
whereas currently it simply gives a few usecs less than 1 ms. 

Linus, Andrew, do you consider this critical enough to be merged to 
the v2.4 tree?

setitimer expire too early (Kernel 2.4)

[Olivier Croquette]

I am refering to this bug:

http://bugzilla.kernel.org/show_bug.cgi?id=4569

A thread led to a patch from Paulo:

http://kerneltrap.org/mailarchive/1/message/59454/flat

This patch has been included in the kernel 2.6.12.

1. How can I easily check if the patch is planned for include in the 2.4?

2. I downloaded the full 2.4.31 source code. The patch appears not to be 
included. Where/Who should I signal that?

Re: setitimer expire too early (Kernel 2.4)

[Willy Tarreau]

Hello Olivier,

On Thu, Jun 30, 2005 at 09:14:50PM +0200, Olivier Croquette wrote:
> 
> I am refering to this bug:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=4569
> 
> A thread led to a patch from Paulo:
> 
> http://kerneltrap.org/mailarchive/1/message/59454/flat
> 
> This patch has been included in the kernel 2.6.12.
> 
> 1. How can I easily check if the patch is planned for include in the 2.4?

Right now, simply by asking Marcelo. As he's moving his tree from BK to
git, I suspect we'll not see any intermediate merge before 2.4.32-pre1.

> 2. I downloaded the full 2.4.31 source code. The patch appears not to be 
> included. Where/Who should I signal that?

Here is a good place. Unfortunately, the thread pointed above ended
quickly, and it does not seem clear from this whether Paulo's patch
should be applied or not, as adding 1 jiffie at 100 Hz will result in
a (noticeable) 10 ms additionnal sleep time. If you know of applications
which break because of this problem, and there is a general consensus
stating that the patch will not break anything, I can issue a 2.4.31-hf1,
but it does not seem critical enough to justify a hotfix.

Regards,
Willy

Re: setitimer expire too early (Kernel 2.4)

[Willy Tarreau]

Hi Marcelo,

you type faster than me :-)

On Thu, Jun 30, 2005 at 01:50:53PM -0300, Marcelo Tosatti wrote:
 
> And what about the side effects:
> This however will produce pathological cases, like having a idle system
> being requested 1 ms timeouts will give systematically 2 ms timeouts,
> whereas currently it simply gives a few usecs less than 1 ms. 

Unless I'm mistaken, it's worse. 1 ms will lead to 11 ms because
HZ is still 100 on most common archs in 2.4. Perhaps we could find
a way to round it_real_incr up instead of systematically adding 1
to interval ?

Cheers,
Willy

Re: setitimer expire too early (Kernel 2.4)

[Andrew Morton]

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
> On Thu, Jun 30, 2005 at 09:14:50PM +0200, Olivier Croquette wrote:
> > 
> > I am refering to this bug:
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=4569
> > 
> > A thread led to a patch from Paulo:
> > 
> > http://kerneltrap.org/mailarchive/1/message/59454/flat
> > 
> > This patch has been included in the kernel 2.6.12.
> > 
> > 1. How can I easily check if the patch is planned for include in the 2.4?
> > 
> > 2. I downloaded the full 2.4.31 source code. The patch appears not to be 
> > included. Where/Who should I signal that?
> 
> And what about the side effects:
> This however will produce pathological cases, like having a idle system
> being requested 1 ms timeouts will give systematically 2 ms timeouts,
> whereas currently it simply gives a few usecs less than 1 ms. 

(20ms rather than 10ms)

> 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.

Re: setitimer expire too early (Kernel 2.4)

[George Anzinger]

Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> 
>>On Thu, Jun 30, 2005 at 09:14:50PM +0200, Olivier Croquette wrote:
>>
>>>I am refering to this bug:
>>>
>>>http://bugzilla.kernel.org/show_bug.cgi?id=4569
>>>
>>>A thread led to a patch from Paulo:
>>>
>>>http://kerneltrap.org/mailarchive/1/message/59454/flat
>>>
>>>This patch has been included in the kernel 2.6.12.
>>>
>>>1. How can I easily check if the patch is planned for include in the 2.4?
>>>
>>>2. I downloaded the full 2.4.31 source code. The patch appears not to be 
>>>included. Where/Who should I signal that?
>>
>>And what about the side effects:
>>This however will produce pathological cases, like having a idle system
>>being requested 1 ms timeouts will give systematically 2 ms timeouts,
>>whereas currently it simply gives a few usecs less than 1 ms. 

I don't see why an idle system would align such request in this way any more 
than a busy one.  In both cases the range would be ~0 to 1ms (which is what the 
standard says it should be) with an average of .5ms.  Any other result is caused 
by syncing, in some way with the tick clock.
> 
> 
> (20ms rather than 10ms)
> 
> 
>>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.

Still, it is the "correct" thing to do (standard wise, etc...).

It is rather amazing that this has been in the system this long.  Should have 
been fixed long ago...

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: setitimer expire too early (Kernel 2.4)

[Marcelo Tosatti]

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.

Re: setitimer expire too early (Kernel 2.4)

[Olivier Croquette]

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?

Re: setitimer expire too early (Kernel 2.4)

[George Anzinger]

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.


-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: setitimer expire too early (Kernel 2.4)

[Marcelo Tosatti]

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.

Re: setitimer expire too early (Kernel 2.4)

[Marcelo Tosatti]

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.