linux-kernel - Re: [PATCH 01/10] -mm: clocksource: increase initcall priority

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:	Mon, 09 Oct 2006 12:24:16 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/10] -mm: clocksource: increase initcall priority

On Mon, 2006-10-09 at 11:50 -0700, john stultz wrote:
> 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.

My main motivation is that I'm assuming other uses of the interface will
exist. Then anything that uses the interface after postcore will avoid
switching clocks later.

If I for instance, just return clocksource_jiffies until the system is
fully booted then any thing that got a clock early, even during part of
device_initcall, would end up switching to a new clock when boot up
finished. I think that was acceptable when just timekeeping might have
been using the interface, but I don't know that it would scale well from
1 to 2 to 5 users of the interface. Then you would have several clock
switches happened after boot up .

> > This also eliminated some clocksource shuffling during bootup.
> 
> Actually, I'm not sure I see this. Which shuffling does it avoid? 

The shuffling that you commented about in kernel/time/clocksource.c
which was the reason for the "finished_booting" flag, and related code.

> 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.

This is something I've struggled with, but it's still and issue with the
current code to a lesser degree. Like cpufreq isn't likely to be used
during bootup, but acpi sleep states might be..

The current code can be classified as avoiding shuffle, but not
eliminating it. Like with the acpi_pm timer, I was thinking I'd just put
it back into device_initcall and assume shuffling might happen in rare
cases.

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/