Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[Thomas Gleixner <tglx@linutronix.de>]

On Sun, 2005-10-16 at 18:34 +0200, Roman Zippel wrote:

> The spec is not really clear and Thomas refusal to explain his design 
> decision is as also not really helpful. :-(

I did explain, why I did the rounding in the way it is implemented. If
you define the fact that I have a different interpretation of SUS than
you as refusal, then we can stop this thread right here.

> He sets the timer resolution to (NSEC_PER_SEC/HZ) which matches no value 
> above and this way he basically creates another virtual timer, which has 
> only little to do with the real kernel timer tick.

As George explained already we return the resolution of the timer as the
value which can be assumed to be the resolution of the event source,
which drives the timer, because that seems to be the only interesting
value for an application programmer. The theoretical resolution of a
jiffie based timer system is NSEC_PER_SEC/HZ. 

So why is NSEC_PER_SEC/HZ creating a virtual timer ? Because the ntp
adjusted resolution per tick is 1% off ?

I really don't see any sense in returning changing resolution values
every 5 minutes due to NTP adjustments. I imagine the happiness of
application programmers which actually do calculations based on such a
resolution value.

And in the logical consequence you would have to save the original
userspace timespec value including the time when the timer is set up and
redo the rounding and calculation every time NTP changes the
NSEC_PER_TICK value for _all_ timers which are related to
CLOCK_MONOTONIC and CLOCK_REALTIME. 

The code does not introduce a virtual timer at all. It uses the ntp
adjusted time reference and guarantees that the timer goes not off
early. Usually it expires with the next tick - of course system load can
delay it further. 

	tglx