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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 08 Oct 2006 10:17:59 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	tglx@...utronix.de
Cc:	akpm@...l.org, johnstul@...ibm.com, mingo@...e.hu,
	zippel@...ux-m68k.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: + clocksource-increase-initcall-priority.patch added to -mm
	tree

On Sun, 2006-10-08 at 18:52 +0200, Thomas Gleixner wrote:
> On Sun, 2006-10-08 at 09:18 -0700, Daniel Walker wrote:
> > > 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. 
> 
> What churn at bootup ? The clocksources _can_ be switched and it does
> not matter, when this is done. We had the trouble with the early
> registration a couple of month ago, and there is no reason to
> reintroduce it. On systems which have exactly one clocksource, you can
> register them early in bootup, but please do not touch the x86 setup for
> no good reason.

There was a special case inside kernel/time/clocksource.c to prevent
clock switching during boot up. If you remove that (which I have) then
you will end up with clock switching happening a few times during bootup
(whenever a new highest rated clock is registered), that's the churn I'm
referring to.

The churn is not optimal. I've used postcore to prevent it, and make the
API usable earlier. So there is a reason for the change. 

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/