* Con Kolivas <[EMAIL PROTECTED]> [050816 06:23]:
> On Tue, 16 Aug 2005 23:19, Srivatsa Vaddagiri wrote:
> > On Tue, Aug 16, 2005 at 02:30:51AM +1000, Con Kolivas wrote:
> > > Time definitely was lost the longer the machine was running.
> >
> > I think I found the reason for time drift. Basically c
On Tue, 16 Aug 2005 23:19, Srivatsa Vaddagiri wrote:
> On Tue, Aug 16, 2005 at 02:30:51AM +1000, Con Kolivas wrote:
> > Time definitely was lost the longer the machine was running.
>
> I think I found the reason for time drift. Basically cur_timer->mark_offset
> doesnt expect to be called from non-
On Tue, Aug 16, 2005 at 02:30:51AM +1000, Con Kolivas wrote:
> Time definitely was lost the longer the machine was running.
I think I found the reason for time drift. Basically cur_timer->mark_offset
doesnt expect to be called from non-timer interrupt handler. Hence it drops
one jiffy from the los
On Mon, Aug 15, 2005 at 09:39:22AM -0700, john stultz wrote:
> The timer_opts interface is the existing interface, my work replaces it
> and separates timekeeping from the timer interrupt.
>
> You can find a cumulative version of my patch here:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0508.
On Mon, 2005-08-15 at 21:17 +0530, Srivatsa Vaddagiri wrote:
> On Sun, Aug 14, 2005 at 12:15:38AM -0400, Kyle Moffett wrote:
> > It may be a good idea to rebase this patch off the new generic time-
> > keeping
> > subsystem that John Stultz is working on.
>
> I _am_ using the new subsystem interf
On Tue, 16 Aug 2005 01:35, Srivatsa Vaddagiri wrote:
> On Sun, Aug 14, 2005 at 10:18:28AM +1000, Con Kolivas wrote:
> > timers that made no progress until interrupts drove the timers on again.
> > I built in both PIT and APIC dyntick mode into the kernel and the default
> > in the way I modified th
On Sun, Aug 14, 2005 at 12:15:38AM -0400, Kyle Moffett wrote:
> It may be a good idea to rebase this patch off the new generic time-
> keeping
> subsystem that John Stultz is working on.
I _am_ using the new subsystem interface (->mark_offset) to catch up with lost
ticks. Only I don't think it is
On Sun, Aug 14, 2005 at 10:18:28AM +1000, Con Kolivas wrote:
> timers that made no progress until interrupts drove the timers on again. I
> built in both PIT and APIC dyntick mode into the kernel and the default in
> the way I modified the patch is for APIC mode to be used if it's built in.
> Af
On Aug 13, 2005, at 20:18:28, Con Kolivas wrote:
It does seems there are some timing issues
with this patch, although it is also quite stable (up for 10 hours
now).
I've had a few interesting messages in my syslog suggesting problems:
Hangcheck: hangcheck value past margin!
and then later on
On Sun, 14 Aug 2005 02:46, Srivatsa Vaddagiri wrote:
> On Sun, Aug 14, 2005 at 12:53:20AM +1000, Con Kolivas wrote:
> > Indeed this fixes it on my P4 so that it does skip ticks. However
> > presumably due to the code change I am having the reverse behaviour from
> > previously - it pauses for ages
On Sun, Aug 14, 2005 at 12:53:20AM +1000, Con Kolivas wrote:
> Indeed this fixes it on my P4 so that it does skip ticks. However presumably
> due to the code change I am having the reverse behaviour from previously - it
> pauses for ages when using PIT - worse so than previously in that if I dont
On Sat, 13 Aug 2005 21:37, Srivatsa Vaddagiri wrote:
> On Sat, Aug 13, 2005 at 04:51:07PM +1000, Con Kolivas wrote:
> > I'm sorry to say this doesn't appear to skip any ticks on my single P4
> > with SMP/SMT enabled.
>
> Con,
> I had enabled skipping ticks only in default_idle routine. So if
On Sat, Aug 13, 2005 at 04:51:07PM +1000, Con Kolivas wrote:
> I'm sorry to say this doesn't appear to skip any ticks on my single P4 with
> SMP/SMT enabled.
Con,
I had enabled skipping ticks only in default_idle routine. So if
you have a different idle route (which I suspect is the case)
On Sat, 13 Aug 2005 11:35, Con Kolivas wrote:
> On Sat, 13 Aug 2005 06:19, Srivatsa Vaddagiri wrote:
> > Hi,
> > Here's finally the SMP changes that I had promised. The patch
> > breaks the earlier restriction that all CPUs have to be idle before
> > cutting of timers and now allows each idle C
On Sat, 13 Aug 2005 06:19, Srivatsa Vaddagiri wrote:
> Hi,
> Here's finally the SMP changes that I had promised. The patch
> breaks the earlier restriction that all CPUs have to be idle before
> cutting of timers and now allows each idle CPU to skip ticks independent
> of others. The patch is
Hi,
Here's finally the SMP changes that I had promised. The patch
breaks the earlier restriction that all CPUs have to be idle before
cutting of timers and now allows each idle CPU to skip ticks independent
of others. The patch is against 2.6.13-rc6 and applies on top of Con's
patch main
Zwane Mwaikambo wrote:
Hello George,
On Fri, 21 Jan 2005, George Anzinger wrote:
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
Hello George,
On Fri, 21 Jan 2005, George Anzinger wrote:
> 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'
Hi!
> > > > 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 differ
On Fri, 21 Jan 2005, Pavel Machek wrote:
> > > > 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 th
Zwane Mwaikambo wrote:
On Fri, 21 Jan 2005, Tony Lindgren wrote:
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.
Tony Lindgren wrote:
* George Anzinger [050120 15:10]:
Tony Lindgren wrote:
* George Anzinger [050119 16:25]:
Tony Lindgren wrote:
* George Anzinger [050119 15:00]:
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 tou
Hi!
> > > 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
* Zwane Mwaikambo <[EMAIL PROTECTED]> [050121 10:27]:
> On Fri, 21 Jan 2005, Tony Lindgren wrote:
>
> > > 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,
On Fri, 21 Jan 2005, Tony Lindgren wrote:
> > 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
* Zwane Mwaikambo <[EMAIL PROTECTED]> [050119 20:02]:
> On Tue, 18 Jan 2005, Tony Lindgren wrote:
>
> > 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:
> >
> > - S
* George Anzinger [050120 15:10]:
> Tony Lindgren wrote:
> >* George Anzinger [050119 16:25]:
> >
> >>Tony Lindgren wrote:
> >>
> >>>* George Anzinger [050119 15:00]:
> >>>
> >>>
> I don't think you will ever get good time if you EVER reprogramm the
> PIT. That is why the VST patch on s
Tony Lindgren wrote:
* George Anzinger [050119 16:25]:
Tony Lindgren wrote:
* George Anzinger [050119 15:00]:
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 interrupti
* George Anzinger [050119 16:25]:
> Tony Lindgren wrote:
> >* George Anzinger [050119 15:00]:
> >
> >>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 interruptin
* Pavel Machek <[EMAIL PROTECTED]> [050119 16:56]:
> Hi!
>
> > > > > > 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
>
On Wed, 2005-01-19 at 15:45 -0800, john stultz wrote:
> On Thu, 2005-01-20 at 00:26 +0100, Thomas Gleixner wrote:
> > On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
> > > I don't think you will ever get good time if you EVER reprogramm the PIT.
> >
> > Why not ? If you have a continous
On Tue, 18 Jan 2005, Tony Lindgren wrote:
> 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
On Wed, 19 Jan 2005 14:59:20 PST, George Anzinger said:
> 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
Hi!
> > > > > 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 patc
Hi!
> > > 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 intere
Thomas Gleixner wrote:
On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
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 ?
Fi
Tony Lindgren wrote:
* George Anzinger [050119 15:00]:
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 all
* Pavel Machek <[EMAIL PROTECTED]> [050119 15:58]:
> Hi!
>
> > > > 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 f
Hi!
> > > 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:
> >
> >
* Pavel Machek <[EMAIL PROTECTED]> [050119 15:47]:
> Hi!
>
> > > > > > 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
Hi!
> > > > > 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
On Thu, 2005-01-20 at 00:26 +0100, Thomas Gleixner wrote:
> On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
> > 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 s
On Wed, 2005-01-19 at 14:59 -0800, George Anzinger wrote:
> 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 ?
tglx
-
To unsubscrib
* George Anzinger [050119 15:00]:
>
> 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
* Pavel Machek <[EMAIL PROTECTED]> [050119 14:06]:
> Hi!
>
> > > > 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
Andrea Arcangeli wrote:
On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
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
On Wed, Jan 19, 2005 at 11:34:20AM -0800, Tony Lindgren wrote:
> It could be HPET that kills it. I don't have any boxes with HPET
> timer, can you try without HPET?
There's no hpet hardware in that system. Also the problem I'm having is
not with your patch but on some code that should be exercised
Hi!
> > > 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 int
Hi!
> > > 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 int
* Tony Lindgren <[EMAIL PROTECTED]> [050119 11:20]:
> * Andrea Arcangeli <[EMAIL PROTECTED]> [050119 11:12]:
> > On Wed, Jan 19, 2005 at 10:19:47AM -0800, Tony Lindgren wrote:
> > > If you have a chance, can you please provide me with some more info
> > > on your system, see my recent reply to Pave
* Andrea Arcangeli <[EMAIL PROTECTED]> [050119 11:12]:
> On Wed, Jan 19, 2005 at 10:19:47AM -0800, Tony Lindgren wrote:
> > 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,
On Wed, Jan 19, 2005 at 10:19:47AM -0800, Tony Lindgren wrote:
> 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 s
* Andrea Arcangeli <[EMAIL PROTECTED]> [050119 09:49]:
> On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
> > 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 skippe
On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
> 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
* Arjan van de Ven <[EMAIL PROTECTED]> [050119 09:31]:
> On Wed, 2005-01-19 at 09:11 -0800, Tony Lindgren wrote:
> > * Pavel Machek <[EMAIL PROTECTED]> [050119 03:32]:
> > > Hi!
> > >
> > > > As this patch is related to the VST/High-Res timers, there
> > > > are probably various things that can be
* Martin Schwidefsky <[EMAIL PROTECTED]> [050119 07:19]:
>
>
>
>
> Stephen Frost <[EMAIL PROTECTED]> wrote on 19/01/2005 03:11:15 PM:
>
> > > 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
>
On Wed, 2005-01-19 at 09:11 -0800, Tony Lindgren wrote:
> * Pavel Machek <[EMAIL PROTECTED]> [050119 03:32]:
> > Hi!
> >
> > > 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.
>
* Stephen Frost <[EMAIL PROTECTED]> [050119 06:11]:
> * 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,
* Pavel Machek <[EMAIL PROTECTED]> [050119 01:44]:
>
> >
> > 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=
* Pavel Machek <[EMAIL PROTECTED]> [050119 03:32]:
> Hi!
>
> > 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
* 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() wh
Hi!
> 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 ti
Hi!
> > 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
Hi!
> 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 time
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 23:09]:
> On Tue, 2005-01-18 at 22:37 -0800, Tony Lindgren wrote:
> > * Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 21:29]:
> > > Hrm... reading more of the patch & Martin's previous work, I'm not sure
> > > I like the idea too much in the
On Tue, 2005-01-18 at 22:37 -0800, Tony Lindgren wrote:
> * Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 21:29]:
> > 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 tic
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 21:29]:
> 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_c
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 21:45]:
> On Tue, 2005-01-18 at 21:21 -0800, Tony Lindgren wrote:
> > * Tony Lindgren <[EMAIL PROTECTED]> [050118 21:08]:
> > > * Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 20:22]:
> > > >
> > > > BTW. Is it possible, when entering the "i
On Tue, 2005-01-18 at 21:21 -0800, Tony Lindgren wrote:
> * Tony Lindgren <[EMAIL PROTECTED]> [050118 21:08]:
> > * Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 20:22]:
> > >
> > > BTW. Is it possible, when entering the "idle" loop, to quickly know an
> > > estimate of when the next tick shou
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
* Tony Lindgren <[EMAIL PROTECTED]> [050118 21:08]:
> * Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 20:22]:
> >
> > 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
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> [050118 20:22]:
> On Tue, 2005-01-18 at 16:05 -0800, Tony Lindgren wrote:
> > 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 follo
On Tue, 2005-01-18 at 16:05 -0800, Tony Lindgren wrote:
> 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:
>
> .../...
Nice, that's exactly what I want on ppc to allow the lap
* Lee Revell <[EMAIL PROTECTED]> [050118 16:22]:
> On Tue, 2005-01-18 at 16:05 -0800, Tony Lindgren wrote:
> > 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
> > i
On Tue, 2005-01-18 at 16:05 -0800, Tony Lindgren wrote:
> 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 interest
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
-
76 matches
Mail list logo
