Re: [Xenomai-core] [RFC][PATCH 4/4] shorten overrun loops of periodic timers

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>  > Gilles Chanteperdrix wrote:
>>  > > Jan Kiszka wrote:
>>  > >  > > I am thinking again about this patch: some handlers need to be
>>  > >  > > rewritten, for example the posix timers handler, because the handler
>>  > >  > > relies on the fact that it is called for every timer expiry to compute
>>  > >  > > the overruns count. So maybe this patch should come with the addition of
>>  > >  > > an xntimer_getoverrun service that computes the overrun count using the
>>  > >  > > tsc ?
>>  > >  > > 
>>  > >  > 
>>  > >  > Mmh, that gets close to hrtimer_forward now: push an overdue timer to an
>>  > >  > expiry date that is in the future and return the number of overruns. But
>>  > >  > do we still want this optimisation of the broken path then? It starts
>>  > >  > getting complex, probably adding more code than it is worth. I'm
>>  > >  > starting to vote against my own patch...
>>  > > 
>>  > > The code to compute the number of overruns from the tsc exists in
>>  > > xnpod_wait_thread_period, is not this just a matter of refactoring this
>>  > > code in an xntimer_getoverrun ?
>>  > > 
>>  > 
>>  > That overrun calculation takes place in thread context, we were
>>  > discussing this for the timer handler. That means, if we generalise, we
>>  > would have to pass the overrun counter somehow from the handler to the
>>  > awakened thread. Would take another struct field, probably in xnthread.
>>  > On the other hand, if that could save code in the posix skin, it may
>>  > make sense.
>>
>> What I had in mind was that timer handlers or threads that are
>> interested in the overruns count could call xntimer_getoverruns, which
>> computes the overruns count "on-the-fly" using the tsc, i.e. without
>> requiring any additional field.
>>
> 
> Mmh, may work. I guess we need some code now. I already rebased my
> series over trunk, I could give this approach a try later.
> 

No, does not work smoothly: While pse51_base_timer_handler would be fine
with xntimer_get_overruns, xnpod_wait_thread_period does its calculation
based on the expiry saved in thread->pexpect. But xntimer_get_overruns
would do this based on the timer object (as its name suggests), and that
expiry will have moved on between the timer handler invocation and the
thread activation. That means xntimer_get_overruns would only be useful
in timer handler context.

Back to square #1 one: What can we gain here? My patch complicates at
least one user, the posix skin, and that only for the sake of slightly
improving a still broken system schedule...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]