[resend] Re: RFC: New event timers infrastructure

[Alexander Motin]

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

For the most of hardware I've seen, reading doesn't need any locking.
Mostly it may be needed if we will try emulate time counter using
hardware that intended to be and used and event timer (like i8254). But
IMHO that it dead end, and whenever it is possible, I would prefer not
to do it. And even so, why locking can't be done just inside the driver
if it is it's own business?

At this moment I am not defining any timer locking at event timer API
(kern_et.c). API only protects timer list access. Timers themselves now
protected by separate lock in consumer which grabbed them
(kern_clocksource.c).

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

What do you mean by daisy-chaining? For example, if we have timer
supporting only periodic mode and two consumers, requiring frequencies
of 100Hz and 127Hz precisely. How do you wish them to chain? What
frequency write into the timer? 12700Hz? If you have no other timers to
live separately - obviously you have to implement some kind of
scheduling. But I believe it is the next level of abstraction, outside
of present API.

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

You mean interrupt latency constraints? Except reasonable callouts time
precision I don't remember other constraints.

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

Not sure what do you mean by "quite userland". This is low-level event
timer hardware abstraction. It is not exposed to user-level and I am not
sure about cases when it should be used even in kernel instead of using
standard callout mechanism or it's possible further tickless successors.

If you wish to work with specific event timer - you can ask et_find() to
give one to you, specifying it's name, and if it is not yet busy - use
if freely for whatever you want.

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

:) It will give you terrible precision or huge interrupt rate.

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

I was talking about this:
http://docs.freebsd.org/cgi/mid.cgi?4C7A5C28.1090904
Trivial scheduling for hardclock, statclock and proflock from single
one-shot hardware event timer implemented at kern_clocksource.c.

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

Are you talking about callback order in case of two simultaneous events?
because if events are not scheduled as simultaneous (up to 64-bit
precision) they could be called respectively to that order. Question is
about interrupt latency or what?

-- 
Alexander Motin