[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080322142502.GA10687@one.firstfloor.org>
Date: Sat, 22 Mar 2008 15:25:02 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Gabriel C <crazy@...galware.org>,
Gabriel C <nix.or.die@...glemail.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
LKML <linux-kernel@...r.kernel.org>,
Adrian Bunk <bunk@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Natalie Protasevich <protasnb@...il.com>,
andi-bz@...stfloor.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: 2.6.25-rc5-git6: Reported regressions from 2.6.24
> CPU0 runs the watchdog timer and schedules it on CPU1.
>
> With NO_HZ enabled CPU1 is in a long idle sleep. At this point of the
> boot process there is probably no timer pending on CPU1, which means
> the idle sleep is infinite.
>
> Now some time later CPU1 gets woken by an interrupt/IPI and runs the
> timer wheel. At this point the pm_timer which is the reference clock
> has already wrapped around, so the watchdog thinks that there is a
In my old original own noidletick code I simply limited all sleeps
to below the wrap around of the primary timer. Wouldn't something
like that work?
In the case of the watchdog i guess it would need to be limited
to the wrap around of multiple timers, at least all that
are used by the watchdog.
I'm not sure just doing this for add_timer_on() only is correct.
After all it could affect any other code not run by add_timer_on()
couldn't it?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists