[resend] Re: RFC: New event timers infrastructure

[Alexander Motin]

Hi.

Cherry G. Mathew wrote:
> On 6/6/2010 10:02 PM, Alexander Motin wrote:
>> I did such things:
>>   - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c).
>> It supports global and per-CPU timers, periodic and one-shot. Provides
>> driver and consumer interfaces for choosing timers and operating them;
> 
> [...]
> 
>> Latest patches can be found here:
>> http://people.freebsd.org/~mav/et.20100606.patch
> 
> Had you considered integrating this api with sys/timetc.h ? Most timer
> devices which can interrupt after a certain period of time, can also
> provide counters, I would imagine ?

I don't see much reasons to do it. These systems are quite different.
The almost only API intersection is device choosing algorithm and even
in that case some device that is perfect as time counter can be the
worst as event timer, so there indeed will be two lists independent
ordered lists.

Another intersection could be in using same tick periods for both time
counter and event timers, but I think it will just mess code. At this
moment event timers accept bintime as periods arguments and time
counters also after adjustments are getting translated into bintime. It
looks much more universal and transparent, especially when system uses
different hardware for time counter and event timer.

There is not so much hardware that can be used as both time counter and
event timer. For example, on x86:
 - i8254 can do both, but preferably not at the same time and never both
with event timer in one-shot mode;
 - RTC - only event timer;
 - LAPIC - only event timer;
 - HPET - both: one time counter and 3-8 event timers;
 - TSC - only time counter;
 - ACPI timer - only time counter.

> I'd be keen to know your thoughts on providing the ability of et
> consumers to daisy chain to a single eventtimer.

I am not sure why it is needed. With my latest work on one-shot mode
timers it is possible to use single timer for any number of events. At
this moments for three: hardclock, statclock, proflock. They are
separated for legacy reasons so I wasn't breaking it for now. Same time,
if we need to have more consumers - we can either add them in the same
way (bad way) or make some king of universal event scheduler for this --
like out callouts callwheel, but without tick period dependency. The
last way in fact will give us really tick-less kernel.

> It would be good for et_find() to query for timers that can guarantee a
> specific resolution/period or below/above.

I don't see problem to do it. I was just not needed. We may even allow
every application to traverse that list to decide what it wants. But for
present purposes I don't see enough reasons to do it. After reviewing
many of our architectures I've fount that x86 probably have more timers
then any other. Most of other platforms have only 1-2 timers (at least
supported now or which I have found). So really complicated algorithm
seems excessive there.

> Finally, I'm curious to know what et_quality implies ? Perhaps it can be
> an indication of the max/min resolution/period available from a given et ?

There is many factors affecting "how good is this timer". Mostly it is
not a question of precision. Usually it is question of functionality,
performance, reliability and so on. At this moment I am manually
assigning qualities in a way that allows kern_clocksource.c code to make
more or less reasonable choice in most of situations. For example, RTC
timer has very high granularity - prefer i8254 instead if possible;
i8254 can't do one-shot mode due to being also an time counter - prefer
LAPIC; if specific LAPIC timer dies in C3 state - it may be a good
reason to prefer HPET.

-- 
Alexander Motin