Re: [Xenomai-core] [RFC] Fix excessive host tick latencies

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2010-04-30 at 23:01 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2010-04-30 at 15:33 +0200, Jan Kiszka wrote:
> >> Hi Philippe,
> >>
> >> I'm not 100% sure if this plugs all remaining wholes in the deferred
> >> host tick processing, but at least the most easiest reproducible one is
> >> cured now for me (Linux latency peak after termination of 'latency').
> >> Please let me know if you see more potential issues, otherwise I would
> >> include this in my for-upstream queue.
> > 
> > That patch is correct, please queue it. Anything that breaks the
> > assumption described in the following comment from
> > xntimer_next_local_shot() is wrong wrt tick deferral: "The host tick
> > deferral is cleared whenever Xenomai is about to yield control to the
> > host kernel".
> > 
> > In short, when the code will match the comments and documentation, we
> > will be done with debugging.
> 
> What I meant is that with the nucleus debugging fixed, we may not even
> enter __xnpod_schedule often enough to handle the host tick propagation.
> So, maybe we should make xnpod_schedule call __xnpod_schedule if XNHTICK
> or XNHDEFER are set.
> 

I got that, but this is ok. Deferral is marked whenever the resched bit
is already set, or we don't run over the root thread, which means that
we will raise the resched bit to switch back to root at some point, and
clear the deferral there. IOW, xnpod_schedule() cannot filter out a
valid condition for clearing the host timer deferral, in any of its
debug/non-debug forms.

-- 
Philippe.