fix jiffies clocksource inittime
PATCH 1/1 fix jiffies clocksource inittime
Andrew,
In debugging a problem w/ the -rt tree, I noticed that on systems that
mark the tsc as unstable before it is registered, the TSC would still be selected and used for a short period of time. Digging in it looks to be a result of the mix of the clocksource list changes and my clocksource initialization changes.
With the -rt tree, using a bad TSC, even for a short period of time can results in a hang at boot. I was not able to reproduce this hang w/ mainline, but I'm not completely certain that someone won't trip on it.
This patch resolves the issue by initializing the jiffies clocksource earlier so a bad TSC won't get selected just because nothing else is yet registered.
thanks
-john
kernel/time/jiffies.c +1 -1
@@ -69,4 +69,4 @@ static int __init init_jiffies_clocksourreturn clocksource_register (&clocksource_jiffies); } -module_init (init_jiffies_clocksource); +core_initcall (init_jiffies_clocksource);
Quoted 24 lines · On Wed, 04 Apr 2007 12:50:15 -0700 john stultz <[email protected]> wrote:
In debugging a problem w/ the -rt tree, I noticed that on systems that
mark the tsc as unstable before it is registered, the TSC would still be selected and used for a short period of time. Digging in it looks to be a result of the mix of the clocksource list changes and my clocksource initialization changes.With the -rt tree, using a bad TSC, even for a short period of time can results in a hang at boot. I was not able to reproduce this hang w/ mainline, but I'm not completely certain that someone won't trip on it.
This patch resolves the issue by initializing the jiffies clocksource earlier so a bad TSC won't get selected just because nothing else is yet registered.
thanks
-johnSigned-off-by John Stultz <[email protected]>kernel/time/jiffies.c +0
-0
kernel/time/jiffies.c static int __init init_jiffies_clocksour · line 72
Quoted 5 lines
kernel/time/jiffies.c +1
-1@@ -69,4 +69,4 @@ static int __init init_jiffies_clocksourreturn clocksource_register (&clocksource_jiffies); } -module_init (init_jiffies_clocksource); +core_initcall (init_jiffies_clocksource);
Do you think this is needed in 2.6.21?
If so: worrisome. Startup ordering issues are fragile and tricky. Time management is fragile and tricky. The combination of the two doesn't get any better ;)
An option would be to test it in 2.6.22-rcX for a while, then backport to 2.6.21.x.
Quoted 5 lines · Andrew Morton
kernel/time/jiffies.c static int __init init_jiffies_clocksour · line 72
Quoted 3 lines
kernel/time/jiffies.c +1
-1-module_init (init_jiffies_clocksource); +core_initcall (init_jiffies_clocksource);Do you think this is needed in 2.6.21?
Yes, please.
Quoted 6 lines
If so: worrisome. Startup ordering issues are fragile and tricky. Time management is fragile and tricky. The combination of the two doesn't get any better ;)
An option would be to test it in 2.6.22-rcX for a while, then backport to 2.6.21.x.
The jiffies clocksource is completely uncritical and it's less worrisome than having the TSC early as the time reference.
tglx
Quoted 30 lines · Andrew Morton
Quoted 27 lines · On Wed, 04 Apr 2007 12:50:15 -0700 john stultz <[email protected]> wrote:
In debugging a problem w/ the -rt tree, I noticed that on systems that
mark the tsc as unstable before it is registered, the TSC would still be selected and used for a short period of time. Digging in it looks to be a result of the mix of the clocksource list changes and my clocksource initialization changes.With the -rt tree, using a bad TSC, even for a short period of time can results in a hang at boot. I was not able to reproduce this hang w/ mainline, but I'm not completely certain that someone won't trip on it.
This patch resolves the issue by initializing the jiffies clocksource earlier so a bad TSC won't get selected just because nothing else is yet registered.
thanks
-johnSigned-off-by John Stultz <[email protected]>kernel/time/jiffies.c +0
-0@@ -69,4 +69,4 @@ static int __init init_jiffies_clocksourreturn clocksource_register (&clocksource_jiffies); }
Quoted 8 lines
kernel/time/jiffies.c static int __init init_jiffies_clocksour · line 72
Quoted 2 lines
kernel/time/jiffies.c +1
-1-module_init (init_jiffies_clocksource); +core_initcall (init_jiffies_clocksource);Do you think this is needed in 2.6.21?
If so: worrisome. Startup ordering issues are fragile and tricky. Time management is fragile and tricky. The combination of the two doesn't get any better ;)
Its likely low-risk, however I'm pretty cautious this close to release.
Quoted 2 lines
An option would be to test it in 2.6.22-rcX for a while, then backport to 2.6.21.x.
I'm fine with this (also getting it into the next -mm would help). But I'd defer to others with stronger opinions.
thanks
-john
Quoted 5 lines · On Wed, 04 Apr 2007 13:53:47 -0700 john stultz <[email protected]> wrote:
Quoted 2 lines
An option would be to test it in 2.6.22-rcX for a while, then backport to 2.6.21.x.
I'm fine with this (also getting it into the next -mm would help). But I'd defer to others with stronger opinions.
No, I wouldn't wait around for -mm testing in a case like this.
Generally, if we plan on getting a patch into 2.6.x this late in the cycle, I will slam it in asap so it gets as much testing as possible.
Oh well, fingers crossed - I'll add it to today's batch.
Quoted 6 lines · Andrew Morton
If so: worrisome. Startup ordering issues are fragile and tricky. Time management is fragile and tricky. The combination of the two doesn't get any better ;)
An option would be to test it in 2.6.22-rcX for a while, then backport to 2.6.21.x.
is the v2.6.21 release so close? From all i can see Adrian Bunk still has a very sizable regressions list, which necessiate a couple of weeks to track down. And the delta since -rc5 is pretty large too, necessiating an -rc6.
Ingo
Quoted 11 lines · On Wed, 4 Apr 2007 23:23:24 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 6 lines · Andrew Morton
If so: worrisome. Startup ordering issues are fragile and tricky. Time management is fragile and tricky. The combination of the two doesn't get any better ;)
An option would be to test it in 2.6.22-rcX for a while, then backport to 2.6.21.x.
is the v2.6.21 release so close?
It's the closest it's ever been!
Quoted 5 lines
From all i can see Adrian Bunk still
has a very sizable regressions list, which necessiate a couple of weeks to track down. And the delta since -rc5 is pretty large too, necessiating an -rc6.
yeah, I wouldn't be surprised to see an rc7.