On 2011-06-18 17:01, Gilles Chanteperdrix wrote:
> On 06/18/2011 04:06 PM, Jan Kiszka wrote:
>> On 2011-06-18 16:01, Gilles Chanteperdrix wrote:
>>> On 06/18/2011 03:47 PM, Jan Kiszka wrote:
>>>> On 2011-06-18 15:40, Gilles Chanteperdrix wrote:
>>>>> On 06/18/2011 03:16 PM, Jan Kiszka wrote:
>>>>>> On 2011-06-18 15:12, Gilles Chanteperdrix wrote:
>>>>>>> On 06/18/2011 03:07 PM, Jan Kiszka wrote:
>>>>>>>> On 2011-06-18 14:56, Gilles Chanteperdrix wrote:
>>>>>>>>>
>>>>>>>>> Maybe in the irq handlers, we should skip the XNHTICK replay, when
>>>>>>>>> current_domain is root_domain.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That would be against the purpose of the XNTICK replay (it only targets
>>>>>>>> that particular case). And it would still leave us with broken ipipe 
>>>>>>>> due
>>>>>>>> to enabled IRQs on return from the Xenomai handlers.
>>>>>>>
>>>>>>> What I mean is that xnintr_clock_handler, we should skip the XNHTICK
>>>>>>> replay when the current domain upon return from xnpod_schedule is not
>>>>>>> root. From what I understand, this case only happens when xnpod_schedule
>>>>>>> migrated the thread, and in that case, the tick will have been forwarded
>>>>>>> during xnpod_schedule anyway.
>>>>>>
>>>>>> In the problematic case, ie. when the XNHTICK replay uses an invalid
>>>>>> sched, the current domain is root. It must be root because only then the
>>>>>> context could have been migrated to a different CPU by Linux. So this
>>>>>> does not help to avoid having to reload sched.
>>>>>
>>>>> I mean replace:
>>>>>   if (testbits(sched->lflags, XNHTICK) &&
>>>>>       xnthread_test_state(sched->curr, XNROOT))
>>>>>           xnintr_host_tick(sched);
>>>>>
>>>>> with
>>>>>   if (!xnarch_root_domain_p() &&
>>>>>       testbits(sched->lflags, XNHTICK) &&
>>>>>       xnthread_test_state(sched->curr, XNROOT))
>>>>>       xnintr_host_tick(sched);
>>>>>
>>>>
>>>> That breaks Linux timer ticks: If we are only running the root thread,
>>>> where should the pending tick be replayed? It is always deferred, even
>>>> over the root domain. And __xnpod_schedule, which could replay it as
>>>> well, is only entered if there is rescheduling required.
>>>
>>> I may be wrong, but it is my understanding that Adeos switches domain 
>>> before executing interrupt handlers, so that the current Adeos domain 
>>> when running xnintr_clock_handler is always Xenomai, except at this 
>>> point if we have migrated. For instance, see the following trace :
>>>
>>>  |   +func                -9296 __ipipe_grab_localtimer+0x10 
>>> (__irq_usr+0x3c)
>>>  |   +func                -9295 __ipipe_grab_irq+0x10 
>>> (__ipipe_grab_localtimer+0x20)
>>>  |   +func                -9295 __ipipe_handle_irq+0x10 
>>> (__ipipe_grab_irq+0x88)
>>>  |   +func                -9295 __ipipe_ack_localtimer+0x10 
>>> (__ipipe_handle_irq+0xc8)
>>>  |   +func                -9294 __ipipe_dispatch_wired+0x10 
>>> (__ipipe_handle_irq+0xd4)
>>>  |   +func                -9293 __ipipe_dispatch_wired_nocheck+0x14 
>>> (__ipipe_dispatch_wired+0x50)
>>>  |  # func                -9293 xnintr_clock_handler+0x14 
>>> (__ipipe_dispatch_wired_nocheck+0x88)
>>>
>>> where we clearly see that the current domain is xenomai when executing
>>> xntintr_clock_handler.
>>
>> Yeah, that's true.
>>
>>>
>>> Anyway, reading ipipe_current_domain is probably as expensive as
>>> reading xnpod_current_sched().
>>>
>>
>> And it would extend the common code path by another test.
> 
> I am not sure I understand the xnstat stuff, but is not the call to
> xnstat_exectime_switch(sched, prev) signalling that the current thread
> is running again (in primary mode)? So, I do not think we can call it
> before xnpod_schedule or after when in root domain will do.

We can. It just comes at the price of that tiny imprecision I've
mentioned. But IRQ handler accounting mostly targets at handler
execution time, not rescheduling effort.

> 
> So, the simplest fix seems to add:
> 
> if (xnarch_root_domain_p())
>       return;
> 
> right after the call to xnpod_schedule.

I would still prefer coding after "CPU and domain are no longer valid
after xnpod_schedule" as a general rule. Keeps us more flexible for the
future. Also, the above would still require to call the trace marks on
exit and to add some explanations.

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