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.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to