[lkml]   [2005]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CONFIG_PRINTK_TIME woes
    "Luck, Tony" <> wrote:
    > It has been pointed out to me that ia64 doesn't boot
    > with CONFIG_PRINTK_TIME=y. The issue is the call to
    > sched_clock() ... which on ia64 accesses some per-cpu
    > data to adjust for possible variations in processor
    > speed between different cpus. Since the per-cpu page
    > is not set up for the first few printk() calls, we die.
    > Is this an issue on any other architecture? Most versions
    > of sched_clock() seem to just scale jiffies into nanoseconds,
    > so I guess they don't. s390, sparc64, x86 and x86_64 all
    > have more sophisticated versions but they don't appear to me
    > to have limitations on how early they might be called.
    > Possible solutions:
    > 1) Fix ia64 version of sched_clock() to check whether
    > the per-cpu page hase been initialized before using it.
    > I don't like this solution as it will make sched_clock()
    > slower for its primary uses in kernel/sched.c ... none of
    > which can be called before the per-cpu area is initialized.
    > 2) Add some test to the printk() path along the lines of:
    > t = (can_call_sched_clock) ? sched_clock() : 0;
    > This is somewhat ugly ... perhaps too unpleasant for words in
    > that can_call_sched_clock is a per-cpu concept!
    > 3) Make the printk() code get the time in some other way.
    > Using sched_clock() here seems wrong. The ia64 version
    > has a big fat comment about not comparing the results of
    > two calls from different cpus ... but since printk() calls
    > can come from any cpu ... it seems likely that a user who
    > turns on PRINTK_TIME might subtract timestamps from two
    > lines to see how long it was between the messages. This
    > could have significant error on a system that has been up
    > for a long time.
    > But I don't have a better suggestion from existing code.
    > I assume that sched_clock() was picked as it is both fast and
    > lockless.

    Yes, using sched_clock() there is a bit abusive.

    It's not terribly performance-sensitive in printk().

    How about we give each arch a printk_clock()?
    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: 2005-08-21 11:21    [W:0.031 / U:0.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site