M. Koehrer wrote: > Hi everybody, > > I am using Xenomai for a high performance real time simulation system. > All of the simulation code is executed within user space. One application is > running that consists > of several Xenomai real time threads. > For performance reasons I am always using the latest PC technology available > (which is currently > Pentium D or Core2Duo PCs, we are thinking even of using quad-core CPUs). > There has to be a kind of thread synchronisation e.g. when accessing shared > data. > Hardware I/O is done via rtnet or via PCI I/O boards that work in user space > aswell (PCI memory > mapped into the user space). > This is done e.g. by using semaphores, mutexes et.c > I like the Xenomai-native skin as it provides a very clear API that is easy > to use. > However, for a user space only application it is a performance killer, that > all API calls > lead to a mode switch from user to kernel space. Each API call takes about > 1-2 microseconds (us) > on my PC which is really expensive. > Especially when inter process communication is used to protect the access to > shared data > it is mostly the case that the calling thread does not have to wait. In this > situation there is no > need for a context switch. The API call did not lead to a rescheduling of the > available tasks. > And for this the required 1-2 us do really hurt. > > Thus my question/proposal is if there is a plan to use a "variant" of the > native API that is optimized for > user space only applications. In this case e.g. futexes can be used. If there > is a need to > reschedule to another task it is fine to "invest" the 2us but it can be > avoided mostly which should > increase the overall performance dramatically.
Your analysis is not wrong. But before going into any detail may I ask you for on clarification: What do you want to optimise *primarily*, the average execution time of your RT threads in order to gain more CPU time for non-RT Linux jobs *or* the worst case execution time of your RT threads? > This would lead to a library where a big part of the functionality is handled > directly in the library > (in user space). Currently the skin passes the (user space) API call via a > Xenomai System call > to the kernel space to execute there the actual functionality. > > Thanks for any feedback on this proposal. > > Regards > > Mathias > Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
