[RFC] Event timers on MIPS

Jayachandran C. c.jayachandran at gmail.com
Tue Jul 27 14:43:32 UTC 2010


On Tue, Jul 27, 2010 at 6:04 PM, Alexander Motin <mav at freebsd.org> wrote:
> Jayachandran C. wrote:
>> On Sun, Jul 18, 2010 at 1:04 AM, Alexander Motin <mav at freebsd.org> wrote:
>>> Jayachandran C. wrote:
>>>> On XLR we would like to use the count/compare which is faster but less
>>>> accurate on all cpus - we can have upto 32 cpus now.  We also have a
>>>> PIC which can provide a better timestamp and timer interrupts.  This
>>>> PIC timestamp can be read from all CPUs but the timer interrupt can be
>>>> delivered to just one CPU at a time.  I think this is how we ended up
>>>> with the current implementation, but any suggestions on how to improve
>>>> this is welcome.
>>
>> As a first step, I have copied the count /compare code from mips with
>> minor modifications into mips/rmi, this lets me boot up (checked in as
>> r210528).
>>
>> I would like to add the PIC based clock next.
>
> Thanks.
>
>>> 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.
>
> Then tick_ticker() function looks broken. counter_lower_last and
> counter_upper should be tracked per-CPU. Otherwise you will have huge
> forward jumps due to false overflows.
>
>> 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?
>
> Yes. And I would leave count/compare also calling tc_init() and
> et_register() as it is now. It won't hurt.
>
>> 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?
>
> I think it can easily be result of broken tick_ticker().

I'm planning to check-in the attached patch for mips/rmi, I think
mips/mips would need something similar.

JC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ticker.patch
Type: text/x-patch
Size: 1625 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20100727/2f405095/ticker.bin


More information about the freebsd-mips mailing list