Wolfgang Mauerer wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Mauerer wrote:
>>>> On the one hand you make complicated code (which will be costly on low
>>>> end hardware) to avoid shutting interrupts around a few assignments, but
>>>> on the other hand you leave an architecture specific function pointer
>>>> call where we want a fast behaviour on average (remember, we do all this
>>>> to avoid a system call, which is only a few hundreds nanoseconds on your
>>>> big iron x86), and where we have a generic fast replacement. Sometimes,
>>>> I do not understand your logic.
>>> But using the same argument, you could get rid of Linux vsyscall based
>>> gettimeofday()...
>> I do not see your point, the Linux code does not go a long way to make
>> lockless code, it simply turns off interrupts around the gtod data
>> update, which is really reasonable given the size of the masking
>> section. The reading is lockless, the writing is not.
>>
> I was referring to the argument that system calls are so fast that
> replacing gtod with a syscall-less version that uses function
> pointer dereferencing instead does not make much of a difference.
That is not what I said. I compared the weight of a function pointer
call with the one of four asignments with irqs off. And yes syscalls are
fast on x86, do the measurements yourself, you may be surprised.
>
> Be it as it may, I need to check how far our budget can cover
> the (much more comprehensive) modifications required for the
> solution suggested by you. Let's see.
I do not think there is that much work involved. The way I see it, we
would need to replace our tsc reading function with one returning
"ntp-corrected" tsc (that is, essentially a subset of the gettimeofday
function you implemented, without conversion to ns and to CLOCK_REALTIME).
Changes in this monotonic clock would trigger a recomputation of the
next timer event date.
Changes in monotonic to real-time conversion would trigger a call to
xnpod_set_time.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
