Date: Sat, 17 Jul 2010 15:38:42 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: mav@freebsd.org Cc: neel@freebsd.org, freebsd-mips@freebsd.org Subject: Re: [RFC] Event timers on MIPS Message-ID: <20100717.153842.466815693171225157.imp@bsdimp.com> In-Reply-To: <4C4205CC.6080700@FreeBSD.org> References: <4C41B4CF.6080409@FreeBSD.org> <AANLkTik8_NGm7nKYXT1d1E4Vj6vYQPWHnnLDi78YnvQD@mail.gmail.com> <4C4205CC.6080700@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <4C4205CC.6080700@FreeBSD.org>
Alexander Motin <mav@freebsd.org> writes:
: 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.
:
: I would prefer to not mix the things.
:
: I think:
: - PIC timestamp looks like the best candidate for system timecounter.
No it doesn't. Reading the PIC is a lot more expensive than reading
the COUNTER register. It would be better to read the PIC from time to
time and correlate it to the COUNTER register, and interpolate the
final result. This would keep the COUNTER register time device on
time and on frequency, while still giving us the speed advantage of
the less accurate COUNTER.
Small differences in the time it takes to get the time of day can make
huge differences in some work loads. We need to be sensitive here
that we're not unduly penalizing the XLR in this case.
: - 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.
I don't know how well synchronized they are between CPUs. I'm not
100% sure that you can count on that on Cavium. I'm looking for my
Cavium docs to see if they say anything about that or not, but given
the number of people using multi-core caviums and some of the code
that runs on them, I'm pretty sure the cycle counters there, at least,
are coherent. I don't have XLR docs.
: - 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.
:
: PS: I've managed to run MALTA kernel with patch under gxemul. It works,
: except time is not going right. But I suppose it is emulator problem, as
: original kernel works the same.
gxemul is known to have time issues.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100717.153842.466815693171225157.imp>