Messages in this thread | | | Subject | Re: + clocksource-increase-initcall-priority.patch added to -mm tree | From | Daniel Walker <> | Date | Sun, 08 Oct 2006 08:45:17 -0700 |
| |
On Sun, 2006-10-08 at 16:53 +0200, Thomas Gleixner wrote: > On Sun, 2006-10-08 at 07:50 -0700, Daniel Walker wrote: > > On Sun, 2006-10-08 at 12:19 +0200, Thomas Gleixner wrote: > > > On Sun, 2006-10-08 at 10:06 +0200, Thomas Gleixner wrote: > > > > On Fri, 2006-10-06 at 18:53 -0700, akpm@osdl.org wrote: > > > > > Since it's likely that this interface would get used during bootup I moved all > > > > > the clocksource registration into the postcore initcall. This also eliminated > > > > > some clocksource shuffling during bootup. > > > > > > > > We had the init call in postcore already. John moved it to module init > > > > to eliminate trouble with unsynced / unstable TSCs, IIRC. > > > > > > > > John, can you please comment on this. > > > > > > It also breaks pmtimer. > > > > OGAWA reported this already. It breaks the case when there is a verified > > read needed, instead of the fast read. I'll fix it. > > I'd like to know, why we need to move that and you did not explain _why_ > it is likely that it is used during bootup.
If the clocksources are registered at the same time as the clocksource users then you end up with users frequently switching clocks during boot up. The original clocksource code solved this by not allowing a real clocksource lookup until after the system fully booted.
However, if you put all the clocksources into postcore initcall, with that being known in advance, and all the users are in lower priority initcalls then you don't need extra code to prevent churn during bootup.
The reason that I think this will get used during boot up is because some of the target users will be instrumentation, and (my prediction anyway) is that some will need to use the interface early. Still even postcore may not be early enough.
Daniel
- 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/
| |