[lkml]   [2006]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 01/10] -mm: clocksource: increase initcall priority
    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.

    > This also eliminated some clocksource shuffling during bootup.

    Actually, I'm not sure I see this. Which shuffling does it avoid?

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-09 20:53    [W:0.020 / U:34.092 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site