Hi all,
I've been using CONFIG_PRINTK_TIME, and I noticed that I get
pretty bad resolution. I'm only getting resolution to the
millisecond, since the default printk_clock() uses
sched_clock(), which just emits jiffy-based values.
I noticed that timerhi and timerlo are constantly updated
inside timer_interrupt() (in arch/mips/kernel/time.c). These
are used in a few places to get sub-jiffy clock resolution.
Are these (timerhi and timerlo) available on all MIPS platforms,
and would they make a good candidate for a better
high-resolution timestamp source for sched_clock() or printk_clock()?
I wrote the following, but I wanted to get feedback on it before
submitting a patch:
unsigned long long printk_clock(void)
{
unsigned long long clock64;
unsigned int count;
if (!mips_hpt_read) {
count = read_c0_count();
} else {
count = mips_hpt_read();
}
write_seqlock(&xtime_lock);
/* Update timerhi/timerlo for intra-jiffy calibration. */
timerhi += count < timerlo; /* Wrap around */
timerlo = count;
clock64 = (((unsigned long long)timerhi)<<32) + timerlo;
write_sequnlock(&xtime_lock);
return clock64*(1000000000ULL/mips_hpt_frequency);
}
EXPORT_SYMBOL(printk_clock);
I'm worried about the use of write_seqlock() in this routine.
It seems like printks called while inside the timer_interrupt
would deadlock. What I'd really like is a write_tryseqlock(), or
a lock just around the timerhi/timerlo update itself (in both
the timer_interrupt routine and here). But I don't
want to introduce a new lock just for this. Especially since the
apparent locus of vulnerability to race condition is so small,
and it's not the end of the world for printk_clock()
to get bogus value on rare occasions.
I could remove the lock in printk_clock(), but if timerhi gets off, I'm
not sure what could get messed up. I have alternate code which
copies timerhi and timerlo, and updates those independently,
turning printk_clock() into a reader-only of the variables.
Would that be better?
Also, will clock64*(1000000000ULL/mips_hpt_frequency)
blow up on 32-bit platforms?
Any comments would be appreciated. Thanks.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================