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

[Roman Zippel]

Hi,

On Mon, 17 Oct 2005, George Anzinger wrote:

> > Where I think it's possible to separate the timer from the interval
> > functionality to get a simpler timer base implementation.
> 
> They are required fields for the POSIX timer.  I think you are saying that
> they should be there and not in the ktime struct, which is part of the POSIX
> timer struct.  Is that right?

Basically, yes. I would take some simpler steps in creating the new timer 
system. Thomas' patch introduces multiple concepts at once, which are hard 
to digest via a simple review. As it looks right now I have to take the 
patch apart myself and split it into simpler patches.

> > > 2. The rounding to the resolution value is explicitly required by the
> > > standard.
> > 
> > 
> > It doesn't explicitly specify which resolution (see the previous mail).
> > It doesn't explicitly specify how this rounding has to be implemented.
> 
> In the timer_settime() call there is only one possible resolution refered to,
> that of the specified clock.  The standard
> says(http://www.opengroup.org/onlinepubs/009695399/functions/timer_settime.html):
> 
> Time values that are between two consecutive non-negative integer multiples of
> the resolution of the specified timer shall be rounded up to the larger
> multiple of the resolution. Quantization error shall not cause the timer to
> expire earlier than the rounded time value.
> 
> This says a) round to the next resolution, and b) don't allow the resulting
> timer to expire early. The implication is that timers are to expire on
> resolution boundries so we need to round such that the expire happens _after_
> the rounded time.
> 
> Am I missing something here?

In short: rounding errors.

Above says IOW if we have a clock with a freqency f and a resolution with
r=10^9/f, we have to round time t up so that it becomes a integer multiple 
i of r, so that once the counter reaches the value i all timer with upto a
time value of i*r are expired.

If we now simply ignore the resolution fraction, we get a rounded value 
which is quickly far away from the real value (with a worst case of r-1 
nsec). This means an explicit rounding is likely only to make things 
worse and any rounding is better done as part of the conversion from/to 
timespec to/from the counter value according to the above rules and even 
this conversion should be avoided as much as possible to minimize rounding 
errors.

> The assumption, that I think you made, that we can let the hardware do the
> rounding runs contrary to one of the main reasons for resolution, i.e. to
> group timers so that we can reduce the system overhead.  Just because we have
> timer hardware with microsecond resolution is not reason enough to offer it to
> the user as handling an interrupt every micro second is way too much overhead,
> and, in most cases, the user doesn't even want to such a fine resolution.

This just means that we have two values to describe a timer, the clock 
resolution describes the precision with which the timer can be programmed 
and the timer precision which describes the maximum frequency of timer 
expiry. I think both values are of interest to user applications, so my 
current preference is to actually export them both properly instead of 
overloading the clock_getres() interface.

The spec allows both resolutions:

"an implementation (is required) to document the resolution supported for 
timers and nanosleep() if they differ from the supported clock resolution"

This means that unfortunately only one can be determined at runtime via 
standard means, so if we are going to create nonportable interfaces, we 
should do it at least properly.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/