High-res-timers part 2 (x86 platform code) take 5.1
Quoted 11 lines
Quoted 4 lines
This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.
I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.
Linus
Hi Linus,
Concurrent has been using previous versions of the Posix timers patch in our 2.4.18 based kernel. I like this interface and would like to see it included in your kernel.
What would make the patch more acceptable? Would it be acceptable if it used a separate queue for the Posix timers and minimized changes to timer.c?
To answer the partial tick question, it's a trade off. If all you need is 1 milli-second resolution, it might not be worth spliting the tick. It's a question of how the overhead to set up a timer compares to the overhead of the higher frequency tick interrupts. If you want micro-second resolution, you need to split the tick.
This is important to folks doing control systems. They get excited about timing jitter and resolution. It is also interesting to folks doing games. It's nice to be able to do short delays by blocking rather than having to spin in a delay loop.
I'd feel better about this being used for critical applications if the games folks beat it up first.
Jim Houston - Concurrent Computer Corp.
Quoted 10 lines · Jim Houston
Quoted 10 lines
Quoted 4 lines
This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.
I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.
Quoted 7 lines
Quoted 1 line
Linus
Hi Linus,
Concurrent has been using previous versions of the Posix timers patch in our 2.4.18 based kernel. I like this interface and would like to see it included in your kernel.
Hi,
I think nobody objects seeing the interface implemented. Maybe just how it's implemented. I did not have a close look, but the concept seems odd at first sight.
Using a individial timer as interrupt source may be a different idea (if avaliable for the particular hardware), but the there must be a balance between busy looping in the kernel and setting up of such an individual interrupt.
The other thing is how to correlate it with the wall clock.
Sorry for not giving answers, I just know the problems...
Regards,
Ulrich
Quoted 27 lines · Ulrich Windl
Quoted 10 lines · Jim Houston
Quoted 10 lines
Quoted 4 lines
This patch, in conjunction with the "core" high-res-timers patch implements high resolution timers on the i386 platforms.
I really don't get the notion of partial ticks, and quite frankly, this isn't going into my tree until some major distribution kicks me in the head and explains to me why the hell we have partial ticks instead of just making the ticks shorter.
Quoted 7 lines
Quoted 1 line
Linus
Hi Linus,
Concurrent has been using previous versions of the Posix timers patch in our 2.4.18 based kernel. I like this interface and would like to see it included in your kernel.
Hi,
I think nobody objects seeing the interface implemented. Maybe just how it's implemented. I did not have a close look, but the concept seems odd at first sight.
Quoted 6 lines
Using a individial timer as interrupt source may be a different idea (if avaliable for the particular hardware), but the there must be a balance between busy looping in the kernel and setting up of such an individual interrupt.
The other thing is how to correlate it with the wall clock.
Ah, yes, that is it in a nut shell. If you try to put the high res timers in a "special" list and not in the same list as the low res stuff, you have ordering issues. It becomes real easy to have the timers expire in the incorrect order.
As to interrupt source and time, the biggest issue is that we don't really have timers that interrupt in "nice" units of time. The PIT, for example, has a tick time (i.e. each count) of 0.838095239 micro seconds. So how are we to figure time from such a tick if we want to use an integer value for HZ.
What my patch suggests is that we use the higher resolution TSC or pm timer (or what ever is available) and just use the PIT to remind us to look at the clock, AND that we keep time in units of that clock. In some ways we already do this, but we are not consistent. For example we advance the time by less than 1 ms each tick, but we still assume that a tick is 1 ms when we set up timers. This leads to standards failures such as that illustrated by:
time sleep 60
which on a 2.5 system will sleep for less than 60 seconds because of this.
Signature · 5 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml