Date: Thu, 09 Sep 2010 15:12:32 +0530 From: "Cherry G. Mathew" <cherry@zyx.in> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure Message-ID: <4C88AC08.7070502@zyx.in> In-Reply-To: <4C8738DA.80604@FreeBSD.org> References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> <4C8738DA.80604@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear Alexander,
On 9/8/2010 12:48 PM, Alexander Motin wrote:
>
> 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.
>
And if it is busy ? I have in mind non system timers, like stuff that
comes on add-on boards, that can be exported timeret.h and interrupt the
CPU. Would exporting such a timer prevent the onboard devices from
utilising that specific timer function because its callback was busy ?
>>> 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.
>
Indeed, but the abstraction could still be maintained. More practically,
a flag could take care of this (TC_COUNTER_NONE or whatever. )
>>
>> 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?
>
To summarise,
My two concerns were:
I)
a) If there is a non-optional device specific callback (like a timer
isr) tied to specific timer on a vendor board
b) a "generic" non-device specific callback that uses the ET
framework and acquires the timer in "a)" before the isr/callback in "a)"
could obtain it.
how can the API ensure that this scenario:
i) doesn't happen
or
ii) can be subsequently rectified
AND
II)
Did the api need to be fleshed out separately of timertc.h ?
This is more of a political question that I don't care much about.
Cheers,
--
cherry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C88AC08.7070502>