Messages in this thread | | | Subject | Re: [PATCH 01/10] -mm: clocksource: increase initcall priority | From | john stultz <> | Date | Mon, 09 Oct 2006 11:50:51 -0700 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |