[resend] Re: RFC: New event timers infrastructure

[Cherry G. Mathew]

On 9/8/2010 12:23 AM, Alexander Motin wrote:
> 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,


I am not so sure this is as bad as it sounds. For eg: wouldn't a 
specific driver backend, like, say the attimer need to protect against 
concurrent port writes via both APIs, eg: from a oneshot event expiry 
callback and an asynchronous counter read callback (from the separate 
APIs) ? And surely, there is some correlation between timer counter 
resolution and event callback period "quality" for a given device ? I do 
see the cleanliness of abstraction you're arguing for, but I'm just 
saying this is perhaps a bit over-engineered ?

> so there indeed will be two lists independent
> ordered lists.
>

Or alternatively, daisy-chained callbacks ? You could have clients 
daisy-chaining callbacks on top of specific timecounters they care about ?

btw, are there any RT constraints that the current event timer callbacks 
need to be worried about ?

> 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.
>

I agree that the abstractions are "clean"er. However, this isn't quite 
userland, is it ? I'm thinking of the case in which a specific hardware 
topology requires a driver to talk to a specific timer device, say, on 
an add-on board of some sort.

> 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;

An ideal opportunity to implement:

{
   mtx_lock_spin(&clock_lock);
   softcounter++;
   mtx_unlock_spin(&clock_lock);
}

:-)


>   - 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,


This is in yet unpublished work, right ? 'cause I see:

+int
+et_init(struct eventtimer *et, et_event_cb_t *event,
+    et_deregister_cb_t *deregister, void *arg)
+{
+
+	if (event == NULL)
+		return (EINVAL);
+	if (et->et_active)
+		return (EBUSY);
...


> 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.
>

I think the key thing I'm worried about here is consumer order. Is there 
a way in which this can be queried/set by consumers ? I imagine a 
generic scheduler would abstract this decision away from consumers as a 
"scheduling policy".

>> 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.
>

Okay. I was thinking in the context of a wider consumer audience.

>> 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.
>

Many thanks for the detailed explanation.

-- 
cherry