dynamic tick patch

Currently supported timers are TSC and ACPI PM timer. Other timers should be easy to add. Both TSC and ACPI PM timer rely on the PIT timer for interrupts, so the maximum skip inbetween ticks is only few seconds at most.

Quoted 5 lines · Tony Lindgren

Currently supported timers are TSC and ACPI PM timer. Other timers should be easy to add. Both TSC and ACPI PM timer rely on the PIT timer for interrupts, so the maximum skip inbetween ticks is only few seconds at most.

An interesting hack if your sound cards interval timer is supported and can interrupt at high enough resolution (currently ymfpci, emu10k1 and some ISA cards) would be to use it as the system timer. Who knows, it might even be useful for games, music and AV stuff that clocks off the sound card anyway. It would probably be easy, ALSA has a very clean timer API.

Hi all,

Attached is the dynamic tick patch for x86 to play with as I promised in few threads earlier on this list.[1][2]

The dynamic tick patch does following:

.../...

Quoted 5 lines · Tony Lindgren

Hi all,

Attached is the dynamic tick patch for x86 to play with as I promised in few threads earlier on this list.[1][2]

Quoted 3 lines

The dynamic tick patch does following:

.../...

Nice, that's exactly what I want on ppc to allow the laptops to have the CPU "nap" longer when idle ! I'll look into adding ppc support to your patch soon.

BTW. Is it possible, when entering the "idle" loop, to quickly know an estimate of when the next tick shoud actually kick in ?

Also, looking at the patch, I think it mixes a bit too much of x86 things with generic stuffs... like pm_idle an x86 thing.

Other implementation details comments: Do you need all those globals to be exported ? And give them better names than "ltt", that makes using of system.map quite annoying ;)

I don't understand your comment about "we must have all processors idle" as well...

So while the whole thing is interesting, I dislike the actual kernel/dyn-tick-timer.c implementation, which should be moved to arch stuff at this point imho.

Quoted 3 lines · Benjamin Herrenschmidt

BTW. Is it possible, when entering the "idle" loop, to quickly know an estimate of when the next tick shoud actually kick in ?

Yes, see next_timer_interrupt() for that.

Quoted 5 lines · Tony Lindgren

Quoted 3 lines · Benjamin Herrenschmidt

BTW. Is it possible, when entering the "idle" loop, to quickly know an estimate of when the next tick shoud actually kick in ?

Quoted 1 line

Yes, see next_timer_interrupt() for that.

Hmmm, or maybe you mean _quick_estimate_ instead of next_timer_interrupt()?

I don't think there's any faster way to estimate the skippable ticks without going through the list like next_timer_interrupt already does. Does anybody have any ideas for that?

Quoted 6 lines · Tony Lindgren

Quoted 5 lines · Tony Lindgren

Quoted 3 lines · Benjamin Herrenschmidt

BTW. Is it possible, when entering the "idle" loop, to quickly know an estimate of when the next tick shoud actually kick in ?

Quoted 8 lines

Quoted 1 line

Yes, see next_timer_interrupt() for that.

Hmmm, or maybe you mean _quick_estimate_ instead of next_timer_interrupt()?

I don't think there's any faster way to estimate the skippable ticks without going through the list like next_timer_interrupt already does. Does anybody have any ideas for that?

No, that's fine, we already have to call it before entering the PM state, so I'll just pass it along and, at the low level, decide how deep to sleep based on that.

I think I should also add some stats on the amount of interrupts, since it would be fairly inefficient to keep entering deep PM state on a machine with typically little timer interrupts but high HW interrupt (Rusty mentions case of packet forwarding routers or that kind of thing)

Quoted 8 lines

No, that's fine, we already have to call it before entering the PM state, so I'll just pass it along and, at the low level, decide how deep to sleep based on that.

I think I should also add some stats on the amount of interrupts, since it would be fairly inefficient to keep entering deep PM state on a machine with typically little timer interrupts but high HW interrupt (Rusty mentions case of packet forwarding routers or that kind of thing)

Maybe some HW timer interrupt mask could be used? Also it would be nice to check for file IO.

Hrm... reading more of the patch & Martin's previous work, I'm not sure I like the idea too much in the end... The main problem is that you are just "replaying" the ticks afterward, which I see as a problem for things like sched_clock() which returns the real current time, no ?

I'll toy a bit with my own implementation directly using Martin's work and see what kind of improvement I really get on ppc laptops.

Quoted 4 lines · Benjamin Herrenschmidt

Hrm... reading more of the patch & Martin's previous work, I'm not sure I like the idea too much in the end... The main problem is that you are just "replaying" the ticks afterward, which I see as a problem for things like sched_clock() which returns the real current time, no ?

Well so far I haven't found problems with time. Since sched_clock() returns the hw time, how does it cause a problem? Do you have some example in mind? Maybe there's something I haven't even considered yet.

Quoted 2 lines

I'll toy a bit with my own implementation directly using Martin's work and see what kind of improvement I really get on ppc laptops.

I'd be interested in what you come up with :)

Quoted 11 lines · Tony Lindgren

Quoted 4 lines · Benjamin Herrenschmidt

Hrm... reading more of the patch & Martin's previous work, I'm not sure I like the idea too much in the end... The main problem is that you are just "replaying" the ticks afterward, which I see as a problem for things like sched_clock() which returns the real current time, no ?

Well so far I haven't found problems with time. Since sched_clock() returns the hw time, how does it cause a problem? Do you have some example in mind? Maybe there's something I haven't even considered yet.

Quoted 4 lines

Quoted 2 lines

I'll toy a bit with my own implementation directly using Martin's work and see what kind of improvement I really get on ppc laptops.

I'd be interested in what you come up with :)

Well, I did a very simple implementation entirely local to arch/ppc/kernel, that basically calls timer_interrupt on every do_IRQ, I don't change timer_interrupt (our implementation already knows how to "catch up" already if missed ticks and knows how to deal beeing called to early as well). Then, when going to idle loop, I "override" the decrementer interrupt setting to be further in the future if next_timer_interrupt() returns more than 1.

Strangely, I got not measurable improvement on power consumption despite putting the CPU longer into NAP mode. Note that this may be very different with earlier (G3 notably) CPUs, since G3 users repeately reported me havign a significant loss in battery life with HZ=1000

Later, I'll do some stats to check how long I really slept, and see if it's worth, when I predict a long sleep, flushing the cache and going into a deeper PM mode where cache coherency is disabled too.

Hrm... reading more of the patch & Martin's previous work, I'm not sure I like the idea too much in the end... The main problem is that you are just "replaying" the ticks afterward, which I see as a problem for things like sched_clock() which returns the real current time, no ?

I'll toy a bit with my own implementation directly using Martin's work and see what kind of improvement I really get on ppc laptops.

Quoted 5 lines · * Benjamin Herrenschmidt ([email protected]) wrote:

Hrm... reading more of the patch & Martin's previous work, I'm not sure I like the idea too much in the end... The main problem is that you are just "replaying" the ticks afterward, which I see as a problem for things like sched_clock() which returns the real current time, no ?

Quoted 2 lines

I'll toy a bit with my own implementation directly using Martin's work and see what kind of improvement I really get on ppc laptops.

I don't know if this is the same thing, or the same issue, but I've noticed on my Windows machines that the longer my laptop sleeps the longer it takes for it to wake back up- my guess is that it's doing exactly this (replaying ticks). It *really* sucks though because it can take quite a while for it to come back if it's been asleep for a while.

Stephen Frost <[email protected]> wrote on 19/01/2005 03:11:15 PM:

Quoted 5 lines

Quoted 5 lines

Hrm... reading more of the patch & Martin's previous work, I'm not sure I like the idea too much in the end... The main problem is that you are just "replaying" the ticks afterward, which I see as a problem for things like sched_clock() which returns the real current time, no ?

Quoted 8 lines

Quoted 2 lines

I'll toy a bit with my own implementation directly using Martin's work and see what kind of improvement I really get on ppc laptops.

I don't know if this is the same thing, or the same issue, but I've noticed on my Windows machines that the longer my laptop sleeps the longer it takes for it to wake back up- my guess is that it's doing exactly this (replaying ticks). It *really* sucks though because it can take quite a while for it to come back if it's been asleep for a while.

That is the while loop that calls do_timer for each missed timer tick. In my very first try in regard to a tick less system it tried to avoid the loop with a new interface that allowed to account several ticks (the posting on lkml and the patch can still be found in the archives,
e.g. http://marc.theaimsgroup.com/?l=linux-kernel&m=98683292412129&w=2)
We could try to revive the idea and add a #ticks parameter to do_timer(), update_process_times and friends. The main obstacle has been ntp with its time adjustments. There is another patch from John Stultz that introduces new time-of-day code, this would take care of the ntp problem (see http://marc.theaimsgroup.com/?l=linux-kernel&m=110247121329835&w=2).

Attached is the dynamic tick patch for x86 to play with as I promised in few threads earlier on this list.[1][2]

The dynamic tick patch does following:

- Separates timer interrupts from updating system time

- Allows updating time from other interrupts in addition to timer interrupt

- Makes timer tick dynamic

- Allows power management modules to take advantage of the idle time inbetween skipped ticks

- Might help with the whistling caps?

The patch should be non-intrusive where possible. The system boots with the regular timers, and then later on switches on the dynamic tick if the selected driver implements get_hw_time() function.

Currently supported timers are TSC and ACPI PM timer. Other timers should be easy to add. Both TSC and ACPI PM timer rely on the PIT timer for interrupts, so the maximum skip inbetween ticks is only few seconds at most.

Please note that this patch alone does not help much with power savings. More work is needed in that area to make the system take advantage of the idle time inbetween the skipped ticks.

Quoted 6 lines

Please note that this patch alone does not help much with power savings. More work is needed in that area to make the system take advantage of the idle time inbetween the skipped ticks.

Well, having HZ=100 instead of HZ=1000 has measurable benefits on power consumption. This should be at least as good, no?

HZ=100 does not allow improving the idle loop much further from what we have. We should be able to take advantage of the longer idle/sleep periods inbetween the skipped ticks.

Quoted 3 lines · Tony Lindgren

HZ=100 does not allow improving the idle loop much further from what we have. We should be able to take advantage of the longer idle/sleep periods inbetween the skipped ticks.

OTOH servers aren't just doing idle power saving, if you're computing wasting 1% of your cpu isn't always desiderable.

You'd need to trap into add_timer to make it a truly dynamic timer, only then it would obsolete the HZ=100. So if there's no timer you run at HZ=100, while if there's some timer pending in the next 10 timer queues you run at HZ=1000.

The main problem I can see with your patch is the accuracy issue with the system time. I couldn't fix the algorithm you're depending on to get accurate system time, and I can guarantee such algorithm never worked accurately here and worst of all it doesn't printk anything (which is why it doesn't printk for your patch), so you only see system time go in the future at an excessive rate (minutes per hour IIRC).

Pavel posted the cli/sti script, that should allow to reproduce the inaccuracy of the algorithm. I had to set HZ=100 by hand to workaround the usb modem irq latency that is about 3/4 msec.

Once in a while such algorithm overstates the number of ticks that have been missed, and so the system time goes 1msec in the future when that happens. I still suspect there might be a bug in such code though. There's an unfixable window between the latch read and the tsc read where an error can happen, but as long as the window is below 0.5msec, it should always be possible to regenerate the accurate timing with the current algo, but in practice it fails to be accurate...

If you have a chance, can you please provide me with some more info on your system, see my recent reply to Pavel in this thread for the

Quoted 2 lines · Tony Lindgren

If you have a chance, can you please provide me with some more info on your system, see my recent reply to Pavel in this thread for the

It's a normal UP athlon 1ghz, it should be quite widespread hardware. I know at least another system that had the problem of system time going in the future with 2.6 at the same rate of mine. Still it could be an hardware issue after all if nobody else can reproduce it. At HZ=100 the system time is again perfectly accurate like in 2.4, so probably at least the PIT is ok.

Quoted 10 lines · Andrea Arcangeli

Quoted 2 lines · Tony Lindgren

If you have a chance, can you please provide me with some more info on your system, see my recent reply to Pavel in this thread for the

It's a normal UP athlon 1ghz, it should be quite widespread hardware. I know at least another system that had the problem of system time going in the future with 2.6 at the same rate of mine. Still it could be an hardware issue after all if nobody else can reproduce it. At HZ=100 the system time is again perfectly accurate like in 2.4, so probably at least the PIT is ok.

I've tested it with a celeron a300 box, tyan s2460 dual athlon, tyan tiger 100 dual p3, and fujitsu p1110 crusoe laptop. Fujitsu I may not have tested with TSC, but others work with both ACPI PM timer and TSC.

Maybe try disabling or enabling ACPI PM timer? Or maybe it does not use TSC or ACPI PM timer, and that there's some bug in my patch that kills the plain PIT timer?

It could be HPET that kills it. I don't have any boxes with HPET timer, can you try without HPET?

Quoted 3 lines · Tony Lindgren

HZ=100 does not allow improving the idle loop much further from what we have. We should be able to take advantage of the longer idle/sleep periods inbetween the skipped ticks.

OTOH servers aren't just doing idle power saving, if you're computing wasting 1% of your cpu isn't always desiderable.

You'd need to trap into add_timer to make it a truly dynamic timer, only then it would obsolete the HZ=100. So if there's no timer you run at HZ=100, while if there's some timer pending in the next 10 timer queues you run at HZ=1000.

The main problem I can see with your patch is the accuracy issue with the system time. I couldn't fix the algorithm you're depending on to get accurate system time, and I can guarantee such algorithm never worked accurately here and worst of all it doesn't printk anything (which is why it doesn't printk for your patch), so you only see system time go in the future at an excessive rate (minutes per hour IIRC).

Pavel posted the cli/sti script, that should allow to reproduce the inaccuracy of the algorithm. I had to set HZ=100 by hand to workaround the usb modem irq latency that is about 3/4 msec.

Once in a while such algorithm overstates the number of ticks that have been missed, and so the system time goes 1msec in the future when that happens. I still suspect there might be a bug in such code though. There's an unfixable window between the latch read and the tsc read where an error can happen, but as long as the window is below 0.5msec, it should always be possible to regenerate the accurate timing with the current algo, but in practice it fails to be accurate... -

I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at http://sourceforge.net/projects/high-res-timers/

Quoted 1 line · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at http://sourceforge.net/projects/high-res-timers/

Well on my test systems I have pretty good accurate time. But I agree, PIT is not the best option for interrupt. It should be possible to use other interrupt sources as well.

It should not matter where the timer interrupt comes from, as long as it comes when programmed. Updating time should be separate from timer interrupts. Currently we have a problem where time is tied to the
timer interrupt.

Quoted 11 lines · Tony Lindgren

Quoted 7 lines · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at http://sourceforge.net/projects/high-res-timers/

Quoted 8 lines

Well on my test systems I have pretty good accurate time. But I agree, PIT is not the best option for interrupt. It should be possible to use other interrupt sources as well.

It should not matter where the timer interrupt comes from, as long as it comes when programmed. Updating time should be separate from timer interrupts. Currently we have a problem where time is tied to the timer interrupt.

In the HRT code time is most correctly stated as wall_time + get_arch_cycles_since(wall_jiffies) (plus conversion or two:)). This is some what removed from the tick interrupt, but is resynced to that interrupt more or less each interrupt.

A second issue is trying to get the jiffies update as close to the run of the timer list as possible. Without this we have no hope of high res timers.

Quoted 12 lines · George Anzinger

Quoted 10 lines · Tony Lindgren

Quoted 1 line · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at http://sourceforge.net/projects/high-res-timers/

Well on my test systems I have pretty good accurate time. But I agree, PIT is not the best option for interrupt. It should be possible to use other interrupt sources as well.

Quoted 5 lines

Quoted 3 lines

It should not matter where the timer interrupt comes from, as long as it comes when programmed. Updating time should be separate from timer interrupts. Currently we have a problem where time is tied to the
timer interrupt.

In the HRT code time is most correctly stated as wall_time + get_arch_cycles_since(wall_jiffies) (plus conversion or two:)). This is some what removed from the tick interrupt, but is resynced to that interrupt more or less each interrupt.

That sounds very accurate :)

Quoted 1 line

A second issue is trying to get the jiffies update as close to the run of the timer list as possible. Without this we have no hope of high res timers.

OK. But if the timer interrupt is separated from updating the time, the next timer interrupt should be programmable to happen exactly when a HRT timer needs it, right?

Hmm, how about using a pool of programmable timers available on the system for the timer interrupts and HRT? Or is one interrupt source always enough?

Quoted 17 lines · Tony Lindgren

Quoted 15 lines · George Anzinger

Quoted 13 lines · Tony Lindgren

Quoted 8 lines · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at
http://sourceforge.net/projects/high-res-timers/

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Well on my test systems I have pretty good accurate time. But I agree, PIT is not the best option for interrupt. It should be possible to use other interrupt sources as well.

Quoted 14 lines

Quoted 9 lines

Quoted 4 lines

It should not matter where the timer interrupt comes from, as long as it comes when programmed. Updating time should be separate from timer interrupts. Currently we have a problem where time is tied to the timer interrupt.

In the HRT code time is most correctly stated as wall_time + get_arch_cycles_since(wall_jiffies) (plus conversion or two:)). This is some what removed from the tick interrupt, but is resynced to that interrupt more or less each interrupt.

That sounds very accurate :)

Quoted 8 lines

Quoted 3 lines

A second issue is trying to get the jiffies update as close to the run of the timer list as possible. Without this we have no hope of high res timers.

OK. But if the timer interrupt is separated from updating the time, the next timer interrupt should be programmable to happen exactly when a HRT timer needs it, right?

First, HRT uses a two phase system of timing. The first phase is the normal timer list expires the timer. The timer is then handed to the high res code which keeps a list of timers that are to expire prior to the next jiffie. An interrupt is scheduled to make this happen. Depending on the hardware available, this can come from the same timer or a different timer. For example on x86 systems with a local apic we use the apic timer to generate this interrupt. It triggers either a tasklet for UP or SMP with out per cpu timers or a soft irq for SMP systems with per cpu timers.

What this means is that, for timers near but just after a jiffie, the run_timer list being late can make the HR timer late.

This code on on sourceforge if you want a closer look...

Quoted 3 lines

Hmm, how about using a pool of programmable timers available on the system for the timer interrupts and HRT? Or is one interrupt source always enough?

Hardware heaven :), but no thanks. A reliable tick generator for the jiffies timer and one additional timer (or one per cpu) works well in the x86.

If you have something like the PPC where you can mess with the timer with out loosing time, that works well also. The correct formulation would be a "clock" that can be read quickly and a timer tied to the same "rock" that uses the same count units as the clock. PARISC has a counter that just counts and a compare register. When they are equal an interrupt is generated. That is a nice set up.

Now the X86 is bad and has little hope of being fixed for these reasons:
a.) the TSC is fast and easy to read but its not clocked at any given frequency and, on some platforms, it changes without notifying the software. b.) the PIT and the PMTIMER are both in I/O space and so take forever to access.
c.) All three of these use different units (but at least the PMTIMER is (supposed to be) related to the PIT clock.
d.) the HPET, again is in I/O space. I suspect that it uses a reasonable "rock" but, as I understand it, it knocks out the PIT and, of course it uses units unrelated to all the others.

Quoted 12 lines · George Anzinger

Quoted 10 lines · Tony Lindgren

Quoted 7 lines · George Anzinger

Quoted 4 lines · Tony Lindgren

* George Anzinger <[email protected]> [050119 15:00]:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

I don't think you will ever get good time if you EVER reprogramm the PIT. That is why the VST patch on sourceforge does NOT touch the PIT, it only turns off the interrupt by interrupting the interrupt path (not changing the PIT). This allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at http://sourceforge.net/projects/high-res-timers/

Well on my test systems I have pretty good accurate time. But I agree, PIT is not the best option for interrupt. It should be possible to use other interrupt sources as well.

But then again reprogramming PIT in my patch should not be that bad, as it's not done under load.

Quoted 18 lines

Quoted 17 lines

Quoted 5 lines

Quoted 3 lines

It should not matter where the timer interrupt comes from, as long as it comes when programmed. Updating time should be separate from timer interrupts. Currently we have a problem where time is tied to the
timer interrupt.

In the HRT code time is most correctly stated as wall_time + get_arch_cycles_since(wall_jiffies) (plus conversion or two:)). This is some what removed from the tick interrupt, but is resynced to that interrupt more or less each interrupt.

That sounds very accurate :)

Quoted 1 line

A second issue is trying to get the jiffies update as close to the run of the timer list as possible. Without this we have no hope of high res timers.

OK. But if the timer interrupt is separated from updating the time, the next timer interrupt should be programmable to happen exactly when a HRT timer needs it, right?

Quoted 3 lines

First, HRT uses a two phase system of timing. The first phase is the normal timer list expires the timer. The timer is then handed to the high res code which keeps a list of timers that are to expire prior to the next jiffie. An interrupt is scheduled to make this happen. Depending on the hardware available, this can come from the same timer or a different timer. For example on x86 systems with a local apic we use the apic timer to generate this interrupt. It triggers either a tasklet for UP or SMP with out per cpu timers or a soft irq for SMP systems with per cpu timers.

What this means is that, for timers near but just after a jiffie, the run_timer list being late can make the HR timer late.

Thanks for explaining that. So basically catching up with jiffies after skipping ticks could easily delay the HRT timer.

If jiffies was calculated from hw timer, updating time after skipping jiffies would be fast, and then this problem would go away, right?

Quoted 3 lines

This code on on sourceforge if you want a closer look...

I'll take a look at it.

Quoted 6 lines

Quoted 2 lines

Hmm, how about using a pool of programmable timers available on the system for the timer interrupts and HRT? Or is one interrupt source always enough?

Hardware heaven :), but no thanks. A reliable tick generator for the jiffies timer and one additional timer (or one per cpu) works well in the x86.

If you have something like the PPC where you can mess with the timer with out loosing time, that works well also. The correct formulation would be a "clock" that can be read quickly and a timer tied to the same "rock" that uses the same count units as the clock. PARISC has a counter that just counts and a compare register. When they are equal an interrupt is generated. That is a nice set up.

Yes, many ARMs have this setup as well.

Quoted 5 lines

Now the X86 is bad and has little hope of being fixed for these reasons:
a.) the TSC is fast and easy to read but its not clocked at any given frequency and, on some platforms, it changes without notifying the software.
b.) the PIT and the PMTIMER are both in I/O space and so take forever to access.
c.) All three of these use different units (but at least the PMTIMER is (supposed to be) related to the PIT clock.
d.) the HPET, again is in I/O space. I suspect that it uses a reasonable "rock" but, as I understand it, it knocks out the PIT and, of course it uses units unrelated to all the others.

The timers on x86 are quite messy...

Tony

I don't think you will ever get good time if you EVER reprogramm the PIT.

Quoted 1 line · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT.

Why not ? If you have a continous time source, which keeps track of "ticks" regardless the CPU state, why should PIT reprogramming be evil ?

Quoted 5 lines · Thomas Gleixner

Quoted 1 line · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT.

Why not ? If you have a continous time source, which keeps track of "ticks" regardless the CPU state, why should PIT reprogramming be evil ?

That's a big if. The problem is that while the PIT has its problems (such as lost ticks), it runs at a known frequency and is reasonably accurate. Time sources like the TSC have the problem that it doesn't run at a known frequency, and thus we have to calibrate it (usually using the PIT). Unfortunately this calibration is not extremely accurate (George can go on to the reasons why), which causes the TSC to be a poor stand alone time source.

That said, the PIT is a poor time source as well, as it does loose ticks and is very slow to access. ACPI PM and HPET are better as they don't have the lost tick problem, but they are still off chip and slower to access then the TSC.

For an example of your ideal continuous timesource, check out the timebase on PPC/PPC64. Other arches also have similar well behaved time hardware.

Quoted 1 line · George Anzinger

I don't think you will ever get good time if you EVER reprogramm the PIT.

Why not ? If you have a continous time source, which keeps track of "ticks" regardless the CPU state, why should PIT reprogramming be evil ?

allows the PIT to be the "gold standard" in time that it is designed to be. The wake up interrupt, then needs to come from an independent timer. My patch requires a local APIC for this. Patch is available at
http://sourceforge.net/projects/high-res-timers/

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

I'd appreciate some comments and testing!

Hi!

Quoted 4 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

Quoted 1 line

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Quoted 6 lines · Pavel Machek

Hi!

Quoted 4 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

Quoted 6 lines

Quoted 1 line

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

Quoted 14 lines · Tony Lindgren

Quoted 6 lines · Pavel Machek

Hi!

Quoted 4 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

Quoted 6 lines

Quoted 1 line

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

tsc is dangerous for this btw; several cpus go either slower or stop tsc entirely during hlt... eg when idle.
I would suggest to not include a tsc driver for this (otherwise really cool) feature.

Quoted 10 lines

Quoted 5 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

Hi!

Quoted 11 lines

Quoted 10 lines

Quoted 5 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Quoted 20 lines

Quoted 11 lines

Quoted 10 lines

Quoted 5 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

Quoted 4 lines

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

Hi!

Quoted 25 lines

Quoted 24 lines

Quoted 11 lines

Quoted 10 lines

Quoted 5 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Quoted 3 lines

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

Okay, so I set CONFIG_HPET. CONFIG_X86_TSC was already set, I wonder why the code did not use it?

Quoted 9 lines

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

Quoted 4 lines

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

Hi!

Quoted 14 lines

Quoted 13 lines

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Quoted 3 lines

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

This machine definitely has TSC... What do I have to do in .config to make it do something interesting? My .config is:

Quoted 18 lines

Quoted 17 lines

Quoted 5 lines

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

Quoted 8 lines

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

Quoted 2 lines

This machine definitely has TSC... What do I have to do in .config to make it do something interesting? My .config is:

I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is optional, otherwise TSC is used.

Hi!

Quoted 21 lines

Quoted 20 lines

Quoted 9 lines

Quoted 9 lines

Quoted 4 lines

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

On patched 2.6.11-rc1:

[Heh, clock is two times too fast, perhaps that makes ntpdate fail? -- yes.

Quoted 8 lines

Quoted 4 lines

root@amd:~# dmesg | grep -i time; for i in 1 2 3 4 5; do ntpdate -b tak.cesnet.cz && sleep 10; done ; date && sleep 10 && date; while [ 1 ]; do date; done | uniq
PCI: Setting latency timer of device 0000:00:11.5 to 64
dyn-tick: Enabling dynamic tick timer
dyn-tick: Timer using dynamic tick

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

This machine definitely has TSC... What do I have to do in .config to make it do something interesting? My .config is:

Quoted 2 lines

I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is optional, otherwise TSC is used.

Okay, so I tried to measure power consumption. Patched kernel seems to be about 200mW better. That's on 22W... I'll see if I can tweak ACPI somehow to decrease it a bit more.

Quoted 6 lines

Quoted 3 lines

Thanks. Looks like you're running on PIT only, I guess my patch currently breaks PIT (and possibly HPET) No dmesg message for " "Using XXX for high-res timesource".

This machine definitely has TSC... What do I have to do in .config to make it do something interesting? My .config is:

I suspect it's the HPET_TIMER, see below. CONFIG_X86_PM_TIMER is optional, otherwise TSC is used.

config renamed from config.orig +2 -2

@@ -103,7 +103,7 @@
 CONFIG_X86_GOOD_APIC=y
 CONFIG_X86_INTEL_USERCOPY=y
 CONFIG_X86_USE_PPRO_CHECKSUM=y
-CONFIG_HPET_TIMER=y
+# CONFIG_HPET_TIMER is not set
 CONFIG_NO_IDLE_HZ=y
 # CONFIG_SMP is not set
 CONFIG_PREEMPT=y

@@ -169,7 +169,7 @@
 CONFIG_ACPI_POWER=y
 CONFIG_ACPI_PCI=y
 CONFIG_ACPI_SYSTEM=y
-# CONFIG_X86_PM_TIMER is not set
+CONFIG_X86_PM_TIMER=y
 # CONFIG_ACPI_CONTAINER is not set
 
 #

Quoted 10 lines

Quoted 5 lines

As this patch is related to the VST/High-Res timers, there are probably various things that can be merged. I have not yet looked at what all could be merged.

I'd appreciate some comments and testing!

Good news is that it does seem to reduce number of interrupts. Bad news is that time now runs faster (like "sleep 10" finishes in ~5 seconds) and that I could not measure any difference in power consumption.

Thanks for trying it out. I have quite accurate time here on my systems, and sleep works as it should. I wonder what's happening on your system? If you have a chance, could you please post the results from following simple tests?

Hi all,

Attached is the dynamic tick patch for x86 to play with as I promised in few threads earlier on this list.[1][2]

The dynamic tick patch does following:

- Separates timer interrupts from updating system time

- Allows updating time from other interrupts in addition to timer interrupt

- Makes timer tick dynamic

- Allows power management modules to take advantage of the idle time inbetween skipped ticks

- Might help with the whistling caps?

Quoted 14 lines · Tony Lindgren

Hi all,

Attached is the dynamic tick patch for x86 to play with as I promised in few threads earlier on this list.[1][2]

The dynamic tick patch does following:

- Separates timer interrupts from updating system time

- Allows updating time from other interrupts in addition to timer interrupt

- Makes timer tick dynamic

Quoted 4 lines

- Allows power management modules to take advantage of the idle time inbetween skipped ticks

- Might help with the whistling caps?

This doesn't seem to cover the local APIC timer, what do you do about the 1kHz tick which it's programmed to do?

Quoted 2 lines

This doesn't seem to cover the local APIC timer, what do you do about the 1kHz tick which it's programmed to do?

Sorry for the delay in replaying. Thanks for pointing that out, I don't know yet what to do with the local APIC timer. Have to look at more.

Quoted 6 lines · Tony Lindgren

Quoted 2 lines

This doesn't seem to cover the local APIC timer, what do you do about the 1kHz tick which it's programmed to do?

Sorry for the delay in replaying. Thanks for pointing that out, I don't know yet what to do with the local APIC timer. Have to look at more.

Pavel does your test system have a Local APIC? If so that may also explain why you didn't see a difference.

Tony, something like the following for oneshot should work, untested of course. Perhaps you could use that for the wakeup interrupt instead?

void setup_oneshot_apic_timer(unsigned int count)

{
	unsigned int lvtt, tmp_value;
	unsigned long flags;

	count *= calibration_result;
	local_irq_save(flags);
	lvtt = ~APIC_LVT_TIMER_PERIODIC | LOCAL_TIMER_VECTOR;
	apic_write_around(APIC_LVTT, lvtt);
	tmp_value = apic_read(APIC_TDCR);
	apic_write_around(APIC_TDCR, (tmp_value
			& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
			| APIC_TDR_DIV_16);

	apic_write_around(APIC_TMICT, count/APIC_DIVISOR);
	local_irq_restore(flags);
}

Quoted 6 lines

Quoted 2 lines

This doesn't seem to cover the local APIC timer, what do you do about the 1kHz tick which it's programmed to do?

Sorry for the delay in replaying. Thanks for pointing that out, I don't know yet what to do with the local APIC timer. Have to look at more.

Pavel does your test system have a Local APIC? If so that may also explain why you didn't see a difference.

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

This doesn't seem to cover the local APIC timer, what do you do about the 1kHz tick which it's programmed to do?

Sorry for the delay in replaying. Thanks for pointing that out, I don't know yet what to do with the local APIC timer. Have to look at more.

Pavel does your test system have a Local APIC? If so that may also explain why you didn't see a difference.

My systems do have APICs, but I prefer them disabled :-).

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Sorry for the delay in replaying. Thanks for pointing that out, I don't know yet what to do with the local APIC timer. Have to look at more.

Pavel does your test system have a Local APIC? If so that may also explain why you didn't see a difference.

My systems do have APICs, but I prefer them disabled :-).

May i ask why? ;)

Quoted 5 lines · Tony Lindgren

Quoted 1 line

This doesn't seem to cover the local APIC timer, what do you do about the 1kHz tick which it's programmed to do?

Sorry for the delay in replaying. Thanks for pointing that out, I don't know yet what to do with the local APIC timer. Have to look at more.

Pavel does your test system have a Local APIC? If so that may also explain why you didn't see a difference.

Tony, something like the following for oneshot should work, untested of course. Perhaps you could use that for the wakeup interrupt instead?

void setup_oneshot_apic_timer(unsigned int count)

{
	unsigned int lvtt, tmp_value;
	unsigned long flags;

	count *= calibration_result;
	local_irq_save(flags);
	lvtt = ~APIC_LVT_TIMER_PERIODIC | LOCAL_TIMER_VECTOR;
	apic_write_around(APIC_LVTT, lvtt);
	tmp_value = apic_read(APIC_TDCR);
	apic_write_around(APIC_TDCR, (tmp_value
			& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
			| APIC_TDR_DIV_16);

	apic_write_around(APIC_TMICT, count/APIC_DIVISOR);
	local_irq_restore(flags);
}

The VST patch on sourceforge
(http://sourceforge.net/projects/high-res-timers/) uses the local apic timer to do the wake up. This is the same timer that is used for the High Res work.

Hello George,

Quoted 3 lines · George Anzinger

The VST patch on sourceforge
(http://sourceforge.net/projects/high-res-timers/) uses the local apic timer to do the wake up. This is the same timer that is used for the High Res work.

I've been meaning to look into it, although it's quite a bit of work going through all the extra code from the highres timer patch.

Thanks,
Zwane

-
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/