Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>
>>Philippe Gerum wrote:
>>
>>
>>>On Tue, 2007-01-02 at 14:56 +0100, Gilles Chanteperdrix wrote:
>>>
>>>
>>>>Philippe Gerum wrote:
>>>>
>>>>
>>>>>On Tue, 2007-01-02 at 14:30 +0100, Gilles Chanteperdrix wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Philippe Gerum wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Tue, 2007-01-02 at 11:20 +0100, Jan Kiszka wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi all - and happy new year,
>>>>>>>>
>>>>>>>>I haven't looked at all the new code yet, only the commit messages. I
>>>>>>>>found something similar to my fast-forward-on-timer-overrun patch in
>>>>>>>>#2010 and wondered if Gilles' original concerns on side effects for the
>>>>>>>>POSIX skin were addressed [1]. I recalled that my own final summary on
>>>>>>>>this was "leave it as it is" [2].
>>>>>>>>
>>>>>>>
>>>>>>>The best approach is to update the POSIX skin so that it does not rely
>>>>>>>on the timer code to act in a sub-optimal way; that's why this patch
>>>>>>>found its way in. Scheduling and processing timer shots uselessly is a
>>>>>>>bug, not a feature in this case.
>>>>>>
>>>>>>There is some work to be done on the posix skin anyway, this will all be
>>>>>>at once. By the way, I tested the trunk on ARM, and I still get a lockup
>>>>>>when the latency period is too low. I wonder if we should not compare to
>>>>>>"now + nkschedlat", or even use xnarch_get_cpu_tsc() instead of "now".
>>>>>
>>>>>You mean as below, in order to account for the time spent in the
>>>>>handler(s)?
>>>>>
>>>>>- while ((xntimerh_date(&timer->aplink) += timer->interval) < now)
>>>>>+ while ((xntimerh_date(&timer->aplink) += timer->interval) <
>>>>>xnarch_get_cpu_tsc())
>>>>> ;
>>>>>
>>>>
>>>>I mean even:
>>>>
>>>> while ((xntimerh_date(&timer->aplink) += timer->interval) <
>>>> xnarch_get_cpu_tsc() + nkschedlat)
>>>> ;
>>>>
>>>>Because if the timer date is between now and now + nkschedlat, its
>>>>handler will be called again.
>>>>
>>>
>>>Ack.
>>>
>>
>>
>>Keep in mind that this code is now a performance regression for the
>>non-overflow case, specifically when xnarch_get_cpu_tsc() costs more
>>than just a simple CPU register access.
>>
>>My previous "leave it as it is" was also due to the consideration that
>>we shouldn't pay too much in hotpaths for things that go wrong on
>>misdesigned systems.
>
>
> What about a greedy version like this.
This version seems to help a bit: starting latency -p 100 on ARM does
not lock up immediately, the latency test runs with some overruns for a
while, and then locks up after a while. latency -p 200 runs with no
overruns, and locks up after a while too.
--
Gilles Chanteperdrix
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
