[RFC] Event timers on MIPS

M. Warner Losh imp at bsdimp.com
Tue Jul 27 14:46:19 UTC 2010


In message: <AANLkTikUpqLeogkqxqWzzejp=7FstHX2wVRWNrYoWGCp at mail.gmail.com>
            "Jayachandran C." <c.jayachandran at gmail.com> writes:
: > I would prefer to not mix the things.
: >
: > I think:
: >  - PIC timestamp looks like the best candidate for system timecounter.
: >  - per-CPU counters could be registered as per-CPU timecounters with
: > set_cputicker() - the main criteria there is a speed.
: >  - if per-CPU counters are synchronized between CPUs - they could be
: > registered as alternative timecounter for people who wish fastest
: > timecounting; if they are not - they are useless in that role.
: >  - both PIC timer and per-CPU comparators should be independently
: > registered as eventtimers - it is better to have two of them to from
: > accounting correctness PoV, and it will allow user to experiment which
: > one he likes more.
: >  - if there is any other timer hardware - it also should be registered -
: > it will give additional flexibility.
: 
: The per-cpu count/compare counters are not synchronized on XLR.

The Octeon processors have a register to force them to be
synchronized.  Once synchronized, except for some weird debug
scenarios, they stay synchronized.

Does the XLR advanced the count counters at the same rate on all the
core at the same time?

: So your suggestion would be to add a PIC based clock which calls
: tc_init() and et_register(), and to leave the set_cputicker() to be
: the count/compare?
: 
: Also, with just the count/compare, I get these print on early mutiuser bootup.
: ---
: calcru: runtime went backwards from 85936878 usec to 236488 usec for
: pid 1286 (rpcbind)
: calcru: runtime went backwards from 7158742 usec to 19700 usec for pid
: 1285 (nfsiod 0)
: calcru: runtime went backwards from 111005442 usec to 305474 usec for
: pid 1257 (syslogd)
: calcru: runtime went backwards from 10740196 usec to 29555 usec for
: pid 1048 (devd)
: --
: Did not get much time to investigate, any idea what the cause  can be?

Is this multicore?

Warner


More information about the freebsd-mips mailing list