Philippe,
(BTW: is this something that should be discussed in the Xenomai group,
or would it be better to move this discussion to the Adeos mailing list?)
I do have question on this. We already discussed this problem earlier,
and I managed to find a very dirty work around for my application: I
added a lot of "dummy" functions to my application, which are spread
over the whole application. By calling these after the mlockall, but
before I switch to RT-mode I manage to eliminate most of the switches.
Philippe Gerum wrote:
> So it's unfortunately possible to experiment such switches on ppc hw for
> now. It is likely happening when the ns value is copied back to a user
> variable for which there is a PTE miss to handle in Linux kernel space
> first. Check the mail archive about "pte", "cow" (copy-on-write) and
> such things.
>
As far as I know (but I can be incorrect here) an interrupt is generated
due to a PTE-miss. This causes the Nucleus to switch to secondary mode,
to allow Linux to process the PTE's. The total latency caused by this
would not be very bad, as you also indicated earlier.
From the earlier discussion:
In such a case, you have likely hit an illustration of the latter issue
which the I-pipe/ppc implementation still suffers from: some page table
entries are missed during real-time operations. As a consequence of
this, the nucleus catches page faults on behalf of RT threads in primary
mode, then switches these threads back to secondary in order to process
the faults, and eventually wire the missing PTEs in. This is something
calling mlockall() does not prevent the application from (like COW).
Now for my question.
When looking at a situation where you have a system running multiple
RT-tasks, when one of them hits an (unexpected) switch, it is possible
that this task will never be switched in again, as the other RT-tasks
might consume all the processor time.
Would it be possible to have the Nucleus, after the page-fault is
processed and the "problem" is fixed, automagically switch the system
back to primary mode?
It is not the real solution to the problem, but it would be a acceptable
workaround for this moment, until a real solution is available.
Also another question on this issue: at this moment I am using kernel
2.6.14(ppc), but I saw that there is now an adeos-patch for
2.6.20(powerpc). Could using this version give an improvement in this
area, or does this not make a difference?
Kind regards,
Johan Borkhuis
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
