RFC - fix for sched_clock/printk_clock bad resolution

[Tim Bird <tim.bird@xxxxxxxxxxx>]

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