On Thu, 1 Sep 2005 02:58 am, Srivatsa Vaddagiri wrote:
> Following patches related to dynamic tick are posted in separate mails,
> for convenience of review. The first patch probably applies w/o dynamic
> tick consideration also.
>
> Patch 1/3 -> Fixup lost tick calculation in timer_pm.c
> Patch 2/3 -> Dyn-tick cleanups
> Patch 3/3 -> Use lost tick information in dyn-tick time recovery
>
> These patches are against 2.6.13-rc6-mm2.
>
> Con, would be great if you can upload a consolidated new version of
> dyn-tick patch on your website!
Great, thanks. I'll wait till 2.6.13-mm1 is out since that's due shortly and
I'll resync everything with that and perhaps tweak along the way.
Cheers,
Con
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -2034,7 +2034,9 @@
.disable = mask_IO_APIC_irq,
.ack = ack_edge_ioapic,
.end = end_edge_ioapic,
+#ifdef CONFIG_SMP
.set_affinity = set_ioapic_affinity,
+#endif
};
#endif
On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
[snip]
> I tried this quickly on a loaner ThinkPad T30, and needed the following
> patch to compile. The patch does work with PIT, but with lapic the
> system does not wake to timer interrupts :(
That may be a thinkpad issue; I have to boot my Thinkpad with nolapic.
[snip]
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
* David Weinehall <[email protected]> [050901 16:19]:
> On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
> [snip]
> > I tried this quickly on a loaner ThinkPad T30, and needed the following
> > patch to compile. The patch does work with PIT, but with lapic the
> > system does not wake to timer interrupts :(
>
> That may be a thinkpad issue; I have to boot my Thinkpad with nolapic.
Yeah, that could be. Or it could be the same old P4 does not wake to
APIC interrupt while P3 does bug :)
Tony
On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
> I tried this quickly on a loaner ThinkPad T30, and needed the following
> patch to compile. The patch does work with PIT, but with lapic the
> system does not wake to timer interrupts :(
Even I have found that enabling lapic breaks it on my T30! I think
that is a T30 issue, as I dont see any other reason why it should not
work (note that I have it tested on some other SMP P4 servers where
it works well).
> I also hacked together a little timer test utility that should go trough
> on a completely idle system with no errors. Also posted it to:
>
> http://www.muru.com/linux/dyntick/tools/dyntick-test.c
>
> Srivatsa, could you try the dyntick-test.c on your system after booting
> to init=/bin/sh to make the system as idle as possible?
Thanks for this test. Will test and let you know how it goes on x86.
ATM I am trying to corner the lost-tick-calculation problem with ACPI
PM timer.
> Unfortunately I cannot debug the APIC issue right now, but I seem to
> have an issue on ARM OMAP where the timer test occasionally fails on
> some longer values, for example 3 second sleep can take 4 seconds.
>
> I don't know yet if this is the problem George Anzinger mentioned with
> next_timer_interrupt(), or if this is OMAP specific. But it only seems
Will let you know if I see it on x86 too.
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
> Srivatsa, could you try the dyntick-test.c on your system after booting
> to init=/bin/sh to make the system as idle as possible?
Tony,
I get this o/p when I run your test on my SMP system with
2.6.13-mm1 + Con's latest patches (including the most recent
lost tick calculation patch that I posted after that).
Testing sub-second select and usleep
Test: select 0ms time: 0.000012s latency: 0.000012s status: OK
Test: usleep 0ms time: 0.000013s latency: 0.000013s status: OK
Test: select 100ms time: 0.099386s latency: -0.000614s status: OK
Test: usleep 100ms time: 0.104019s latency: 0.004019s status: OK
Test: select 200ms time: 0.200013s latency: 0.000013s status: OK
Test: usleep 200ms time: 0.204016s latency: 0.004016s status: OK
Test: select 300ms time: 0.300043s latency: 0.000043s status: OK
Test: usleep 300ms time: 0.304056s latency: 0.004056s status: OK
Test: select 400ms time: 0.400010s latency: 0.000010s status: OK
Test: usleep 400ms time: 0.404098s latency: 0.004098s status: OK
Test: select 500ms time: 0.499992s latency: -0.000008s status: OK
Test: usleep 500ms time: 0.504000s latency: 0.004000s status: OK
Test: select 600ms time: 0.600050s latency: 0.000050s status: OK
Test: usleep 600ms time: 0.603959s latency: 0.003959s status: OK
Test: select 700ms time: 0.699969s latency: -0.000031s status: OK
Test: usleep 700ms time: 0.704037s latency: 0.004037s status: OK
Test: select 800ms time: 0.800026s latency: 0.000026s status: OK
Test: usleep 800ms time: 0.803978s latency: 0.003978s status: OK
Test: select 900ms time: 0.900046s latency: 0.000046s status: OK
Test: usleep 900ms time: 0.904003s latency: 0.004003s status: OK
Testing multi-second select and sleep
Test: select 0ms time: 0.000005s latency: 0.000005s status: OK
Test: sleep 0ms time: 0.000006s latency: 0.000006s status: OK
Test: select 1000ms time: 1.000062s latency: 0.000062s status: OK
Test: sleep 1000ms time: 1.004069s latency: 0.004069s status: OK
Test: select 2000ms time: 2.000727s latency: 0.000727s status: OK
Test: sleep 2000ms time: 2.004141s latency: 0.004141s status: OK
Test: select 3000ms time: 3.000127s latency: 0.000127s status: OK
Test: sleep 3000ms time: 3.004048s latency: 0.004048s status: OK
Test: select 4000ms time: 4.000032s latency: 0.000032s status: OK
Test: sleep 4000ms time: 4.004827s latency: 0.004827s status: OK
Test: select 5000ms time: 5.000118s latency: 0.000118s status: OK
Test: sleep 5000ms time: 5.004131s latency: 0.004131s status: OK
Test: select 6000ms time: 5.997241s latency: -0.002759s status: OK
Test: sleep 6000ms time: 6.008025s latency: 0.008025s status: OK
Test: select 7000ms time: 6.997195s latency: -0.002805s status: OK
Test: sleep 7000ms time: 7.004180s latency: 0.004180s status: OK
Test: select 8000ms time: 8.000512s latency: 0.000512s status: OK
Test: sleep 8000ms time: 8.008116s latency: 0.008116s status: OK
Test: select 9000ms time: 8.996997s latency: -0.003003s status: OK
Test: sleep 9000ms time: 9.004279s latency: 0.004279s status: OK
Don't see any ERROR status. The negative latencies doesn't seem to sound
good. Do you see them too? I ran your test on my RH9 based T30 and
find several negative latencies there too.
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
On Fri, Sep 02, 2005 at 11:04:32PM +0530, Srivatsa Vaddagiri wrote:
> On Thu, Sep 01, 2005 at 04:07:22PM +0300, Tony Lindgren wrote:
> > Srivatsa, could you try the dyntick-test.c on your system after booting
> > to init=/bin/sh to make the system as idle as possible?
>
> Tony,
> I get this o/p when I run your test on my SMP system with
> 2.6.13-mm1 + Con's latest patches (including the most recent
> lost tick calculation patch that I posted after that).
...
>
> Don't see any ERROR status. The negative latencies doesn't seem to sound
> good. Do you see them too? I ran your test on my RH9 based T30 and
> find several negative latencies there too.
Good, thanks for testing.
> Test: select 3000ms time: 3.000127s latency: 0.000127s status: OK
This is when I started seeing errors. Looks like if the next event from
next_timer_interrupt() is longer than HZ and idle HZ is very low, such
as 3 - 4 HZ, something gets confused.
I'll be looking into it more a bit later on, but until the problem
is solved, we should limit MAX_SKIP_TICKS to HZ/2.
Tony