On Thu, 2004-07-22 at 17:12, Marc Kleine-Budde wrote: > Hi Philippe! > > Jan and me have made some performance tests with my skin/pod for > xenomai. The skin extends xenomai in a way that the scheduler can > schedule threads in userspace. Calls to the Xenomai nucleus are done > over the common xenomai syscall mechanism. It is also possible to use my > skin in kernelspace, so that ''normal'' Xenomai kernelspace threads are > created. >
Hmm, the fact is that Xenomai already provides the dual kernel/user-space task support. I must have been missing something, but what's the added value of your skin wrt to the basic shadow support? > I've ported the fusion demo (nanosleep and sema4 handshake) example to > my userspace aswell as to kernelspace. Also I've recently ported my skin > to vesuvio in order to use the aperiodic timer. > > The specs of the testmachine: > Pentium III (Coppermine), 933 MHz, Debian Testing, X11 fluxbox, Konsole > rtai-3.1 cvs co from this afternoon, linux-2.4.26 with Adeos 2.4r13/x86 > gcc version 3.3.4 (Debian 1:3.3.4-3) > > My skin uses the apeiodic timer, its nanosleep code is copied/inspiered > by xnshadow_substitute_syscall's nanosleep. > > first: the fusion demo (with my skin used from userspace) > --------------------------------------------------------- > > # while true; do echo `seq 1 46`; done > nanosleep jitter: min = 8382 ns, max = 56289 ns, avg = 29422 ns > sema4 handshake: min = 3847 ns, max = 26440 ns, avg = 12046 ns > > # while true; do echo `seq 1 46`; done > # virtual destop switching in X > nanosleep jitter: min = 9537 ns, max = 123902 ns, avg = 30370 ns > sema4 handshake: min = 3855 ns, max = 43500 ns, avg = 12672 ns > Never put X in the loop; results cannot be reliable with it and it makes no sense to interpret them since the user-space X driver can do whatever it wants to with your hadware, especially when switching back and forth vt7. So I cannot comment these figures. > # idle > nanosleep jitter: min = 9047 ns, max = 58851 ns, avg = 11766 ns > sema4 handshake: min = 3738 ns, max = 20652 ns, avg = 4435 ns > > > > second: the fusion demo (with my skin used from kernelspace) > ------------------------------------------------------------ > (the avg. ist broken, due to longlong math in kernelspace) > > # while true; do echo `seq 1 46`; done > nanosleep jitter: min = 9426 ns, max = 52252 ns, avg = 19675040398 ns > sema4 handshake: min = 1885 ns, max = 21362 ns, avg = 9745 ns > > # while true; do echo `seq 1 46`; done > # virtual destop switching in X > nanosleep jitter: min = 9248 ns, max = 66511 ns, avg = 19675038715 ns > sema4 handshake: min = 1904 ns, max = 32219 ns, avg = 9329 ns > > # idle > nanosleep jitter: min = 7817 ns, max = 50322 ns, avg = 19675023026 ns > sema4 handshake: min = 1855 ns, max = 17000 ns, avg = 2339 ns > > > > third: lxrt testsuite/user/latency > ---------------------------------- > > # while true; do echo `seq 1 46`; done > # virtual destop switching in X > *** min: 1002, max: 21098 average: 3109 <Hit [RETURN] to stop> *** > > # idle > *** min: 1006, max: 15761 average: 2190 <Hit [RETURN] to stop> *** > > > Philippe, can you explain why we have such a high nanosleep jitter? Of > course there is a certain overhead if we schedule userspace threads, but > the kernel-only example shows jitter of the same magnitude. > Because vesuvio (and kilauea) implementation uses a threaded interrupt model and internal mutexes that proved to be nice on the paper but inefficient performance-wise; this is why I killed them from the fusion branch. In order to have the latest performance figures for Xenomai, you should do your tests on fusion, since recent optimizations to the scheduler, interrupt model and aperiodic timer went there, and cannot be backported without heavily changing the Xenomai support in vesuvio, which I won't do. > regards - marc -- Philippe.
