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

[George Anzinger]

Roman Zippel wrote:
> Hi,
>
> On Mon, 17 Oct 2005, Thomas Gleixner wrote:
>
>
> > On Mon, 2005-10-17 at 18:25 +0200, Roman Zippel wrote:
~
> > interval, overrun:
> > Interval holds the converted interval value for itimers. The overrun
> > member is used by the rearm code so the caller can figure out the number
> > of missed events. 
> >
> > The cleanup I pointed out for the posix timer interval timers is pretty
> > obvious. It makes use of interval and overrun and removes two members of
> > the posix timer structure.
>
>
> 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?

Along this line, I have a bit of a problem with the ktimer code doing the timer repeat stuff.  This 
is NOT used by POSIX timers because we want to wait for the user to pick up the signal before 
starting the next interval.  This is key to avoiding timer storms and I would think that puting the 
repeat stuff in ktimer code opens it to the possibility of other users starting a timer storm via 
this.  I think the itimer code should also use the signal call back to start the next interval, and 
for the same reason.
>
~
> > > - resolution handling: at what resolution should/does the kernel work and 
> > > what do we report to user space. The spec allows multiple interpretations 
> > > and I have a hard time to get at least one coherent interpretation out of 
> > > Thomas.
> >
> > I interpret the spec in the way I do for following reasons:
> >
> > 1. It is _usual practice_ to return the "timer" resolution for
> > clock_res() and to return clock values with as much resolution as
> > possible. In no case should the actual clock resolution be less than
> > what clock_res() returns.
> > - George Anzinger in this thread. Similar opinions can be found via
> > Google. I came to the same conclusion and saw no reason to repeat
> > Georges statement. I thought a simple pointer would be sufficient.
>
>
> In this case you don't interpret the spec, you ignore the spec. (I'll 
> leave it open whether that's a good or bad thing.)

Eh?  Granted we don't truncate the time on settime, but how else is it ignored?
> > 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?

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.
> > 3. It makes a lot of sense to do what (1.) describes, due to the fact
> > that we actually want to restrict the timer resolution to avoid
> > interrupt and reprogramming floods in very short intervals. This in fact
> > is the default behaviour in a jiffy driven environment. Pretending a
> > real nsec resolution and doing no rounding at all is violating (2.).
> > > From an application programmers view it makes sense to return the timer
> > resolution so he actually can adjust the program behaviour on the
> > provided resolution and not rely on wild guess assumptions about what
> > might be there. Applications need to be able to verify whether the
> > system can handle the required intervals or not.
>
>
> A portable application simply cannot make this assumption.

POSIX clocks and timers are part of the REAL TIME POSIX extension.  Arguing that real time apps need 
to be portable is, I think, rather beside the point.  At the same time, if rounding follows the 
rules, one can set up a timer_settime() timer_gettime() sequence to get the resolution, even with 
the itimer one can do this.  So resolution is available to the user in one way or another.  What he 
does with it is up to him, but at least some RT apps. set up timer to expire early and after expiry, 
busy wait until the "appointed" time.  Knowing the resolution helps to know how to set this up...
~
--
George Anzinger   george@xxxxxxxxxx
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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/