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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
