High-res-timers part 2 (x86 platform code) take 5.1
Quoted 7 lines · george anzinger
Quoted 4 lines · Linus Torvalds
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
Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.
Seems reasonable to me. Increasing HZ adds overhead - it makes sense to incur the interrupt overhead only when it's needed. In my case, we want to provide fairly precise network delays (we're doing a WAN simulator), and still hit
line rate. Now, I'm way far from the code, but I suspect that
the interrupt overhead needed to get the precision the customer is calling for would be totally prohibitive. I dunno if we'll get the precision the customer wants with George's approach, but we'll get a lot closer than we would setting HZ to 10000 on our wimpy little embedded platform.
George's approach would work a lot better when doing lots of UML VM's on a single box, too, wouldn't it?
- Dan
Quoted 12 lines
Quoted 9 lines · george anzinger
Quoted 4 lines · Linus Torvalds
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 7 lines
Making ticks shorter causes extra overhead ALL the time, even when it is not needed. Higher resolution is not free in any case, but it is much closer to free with this patch than by increasing HZ (which, of course, can still be done). Overhead wise and resolution wise, for timers, we would be better off with a 1/HZ tick and the "on demand" high-res interrupts this patch introduces.
I would like to add my small vote for including the timers too.
I have not looked at the code, but the idea seems sound (let those who need the timers pay the price at that time, don't make the rest of the machine suffer otherwise)....
Enjoy,
Ben
Signature · 3 lines
Ben Greear <[email protected]> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
Quoted 2 lines · [email protected] said:
George's approach would work a lot better when doing lots of UML VM's on a single box, too, wouldn't it?
My thinking on this is that I'll have UML do the on-demand ticks. So, on a host with n UMLs, we will no longer have n * HZ timer deliveries/sec.
I haven't thought a lot about it, but this seems largely unconnected to how the host does its timers.
The one connection I can think of is that any generic support for on-demand ticks would be re-used by UML. And if UML required generic changes for this, then that would obviously affect the other ports somehow.
Jeff
Quoted 9 lines · Jeff Dike
Quoted 2 lines · [email protected] said:
George's approach would work a lot better when doing lots of UML VM's on a single box, too, wouldn't it?
My thinking on this is that I'll have UML do the on-demand ticks. ... any generic support for on-demand
ticks would be re-used by UML. And if UML required generic changes for this, then that would obviously affect the other ports somehow.
Yes, exactly. UML wants on-demand ticks, which is exactly what George's patch
uses, too. I'm too far from the code to say, but there ought to be some commonality there.
- Dan
Quoted 3 lines · Dan Kegel
line rate. Now, I'm way far from the code, but I suspect that
the interrupt overhead needed to get the precision the customer is calling for would be totally prohibitive. I dunno if we'll
only in a fixed interval tick system. Early in george's design process I argued for a tickless system,(which I had implemented in my company's proprietary real-time OS) which has _no_ extra overhead and does away with the 10ms tick entirely. the precision attained is whatever the highest resolution interrupting counter on the system is capable of.
george did extensive benchmarking of candidate implementations of both designs and came to the conclusion that the 10ms jiffie fixed interval tick plus on demand higher resolution ticks was more suitable for general purpose uses than the tickless system, particularly under high load when there are many low resolution timed events in the system (as in a server situation).
it turned out that the tickless system was appropriate for embedded systems (my focus) which tend to have small numbers of well coordinated tasks running and not so good in environments with a lot of things going on, such as a multimedia desktop or big honkin server.
whith the hybrid system that george developed, you get the batching benefits of low resolution fixed interval timers, which provides all the capability most timer services customers need while at the same time, and for minimal overhead providing the high resolution timers that the embedded world needs.
Signature · 3 lines
/************************************************** ** Mark Salisbury || [email protected] ** **************************************************/