On Fri, 2006-10-06 at 11:54 -0700, Daniel Walker wrote:
> plain text document attachment (clocksource_init_call.patch)
> Since it's likely that this interface would get used during bootup
> I moved all the clocksource registration into the postcore initcall.
So this is still somewhat of an open question: While timekeeping_init
runs quite early, and the timekeeping subsystem and its interface is
usable early in the boot process, currently not all the clocksources are
available as early. This is by design, as there may be clocksource
driver modules loaded later on in the boot process, so we don't want to
require it early.
So, the question becomes: Do we want to start using arch specific
clocksources as early as possible, with the potential that we'll replace
it when a better one shows up later? It would allow for finer grained
timekeeping early in boot, which sounds nice, but I'm not sure how great
the real need is for that.
> This also eliminated some clocksource shuffling during bootup.
Actually, I'm not sure I see this. Which shuffling does it avoid?
I suspect it might actually cause more shuffling, as some clocksources
(well, just the TSC, really.. its such a pain...) are not disqualified
until later because we don't know if the system will enter C3, or change
cpufreq, etc.. By waiting longer, we increase the chance that those
disqualifying actions will occur before we install it.
thanks
-john
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
