Re: + clocksource-increase-initcall-priority.patch added to -mm tree

[Daniel Walker <dwalker@mvista.com>]

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/