Subject: Re: evbmips and MIPS3 timecounters committed
To: Frank Kardel <kardel@NetBSD.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-evbmips
Date: 09/01/2006 23:06:38
Frank Kardel wrote:
> Garrett D'Amore wrote:
>
>> Frank,
>>
>> I've committed evbmips support for timecounters using
>> mips3_cp0_counter. It was fairly trivial. It _looks_ good so far, but
>> if you have any suggestions I'd love to hear them.
>>
>>
> Great ! Glad to hear that it was reasonably easy. Could you run the
> sleep regression test to see whether the relation between clock interrupt
> handling and counter reading stays in a reasonable relationship.
> (cd regress/sys/kern/sleeping && make regress) on an unloaded machine
> (scheduling/paging can make the test fail).
I'll run the regression later. My test machine has tiny memory and runs
over NFS, so I can't promise that those won't impact the results. This
is the nature of the embedded port. :-) But at least with a 10 second
test, sleep and /bin/time seemed to correlate and match an external
stop-watch.
>
>> I'm CC'ing the evbmips crowd on this, and the port-mips crowd, because
>> they might want to borrow the logic. It is pretty much the same way on
>> any MIPS3 class cpu.
>>
>>
>>
> Would it be possible to refactor the part for all mips 3 based ports?
Yes. There isn't much there actually. I even considered doing this in
arch/mips/, but right now the mips ports do their clock setup each
separately. So it takes some effort (not much) to do that.
In any case, I'm just using a function to read the cp0 value which
already exists, and is implemented in fast assembly. (I don't even need
to use a wrapper function, so there isn't even an extra call frame. The
end result is that I think it is as fast as it can be.)
>
>> I've only tested AR5312, but it was done in evbmips common code, so I
>> expect it will just work everwhere.
>>
>> Btw, I looked at kern_clock.c -- it will be really, really nice to
>> eliminate the legacy support once we get the other ports committed.
>>
>>
>>
> Yes - I'd like to do the unifdef run rather sooner than later but that
> depends
> a bit on the ports converting (no news). Blind conversions (It
> compiles - ship it!)
> are in my experience a bit risky - things are very easy to mess up.
Sure. :-) That's why I'm not converting any others, even though
converting a bunch of the mips ports would _probably_ be safe.
>
>> Sample output:
>>
>> nano# sysctl -a | grep timecount
>> kern.timecounter.choice = mips_cp0(q=0, f=110000000 Hz)
>> clockinterrupt(q=0, f=100 Hz) dummy(q=-1000000, f=1000000 Hz)
>> kern.timecounter.hardware = mips_cp0
>> kern.timecounter.timestepwarnings = 0
>>
>>
>> - Garrett
>>
>>
>>
> I marked the switch on http://www.kardel.name/timecounters-status.html
> which also
> contains the analysis what work ist left to do for the ports
> (including re-factoring hints).
Thanks.
>
> Thanks again for the next timecounter port.
Thanks for doing the "hard part". :-)
-- Garrett
>
> Frank
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191