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

[Daniel Walker <dwalker@mvista.com>]

On Sun, 2006-10-08 at 17:58 +0200, Thomas Gleixner wrote:
> On Sun, 2006-10-08 at 08:45 -0700, Daniel Walker wrote:
> > > 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.
> 
> No, that was not the reason. It does not hurt anything, when the
> clocksource changes during bootup. You simply replace one read out
> device by another one.
> 
> The reason was that we wanted to select clocksources as late as
> possible, as we wanted to have late init clocksources ready and TSC
> problems outruled.

I think we're going to need to wait for John to comment. His last
comment on this patch was in agreement as long as it solved the churn
issue (as of Aug. 4 on LKML).

> > 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.
> 
> Early bootup Instrumentation is really not a good argument to make that
> fragile time related stuff even more complex. There is no problem to
> register reliable clocksources in early bootup, but do not make this
> mandatory. Not every system is an ARM SoC, where you can and must rely
> on the one source which is available usually right when the CPU comes
> up.

It's not mandatory, it's just preferred.. As I said above, to avoid
churn. I don't like the churn at boot up, and I tried to make sure there
was none added in the patch set. 

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/