RFC - fix for sched_clock/printk_clock bad resolution

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