"Luck, Tony" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |