Re: [Xenomai-core] [RFC] FPU support
Gilles Chanteperdrix wrote: > Paul wrote: >> Hi Giles >> >> On Tuesday 27 January 2009, Gilles Chanteperdrix wrote: >>> So, the question is: are there people around who either: >>> - need FPU support for kernel-space real-time threads; >>> - do not want to pay the price of a trap when using the FPU in user-space. >> One application that I work on uses floating point math in kernel space, but >> it is a constant source of problems - Being forced to migrate to user space >> would be a welcome move.. The only question is how much of an overhead does >> the trap incur ? > > The answer probably depends on the machine. You can probably estimate it > for x86 by using rdtsc in well chosen places. What you need to measure > is the time between the fpu fault in user-space and the beginning of the > fpu fault handler in kernel-space, then the time between the end of the > fpu fault handler and the return to user-space. > Enabling the I-pipe tracer would help in determining how many cycles are burnt from early trap handling back to the supervisor exit point; if you do this, you may want to keep IPIPE_DEBUG_CONTEXT off, since this adds some overhead on low end hw. user/supervisor transition time would have to be added as well, but this is likely not the most significant portion of the overhead. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] FPU support
Paul wrote: > Hi Giles > > On Tuesday 27 January 2009, Gilles Chanteperdrix wrote: >> So, the question is: are there people around who either: >> - need FPU support for kernel-space real-time threads; >> - do not want to pay the price of a trap when using the FPU in user-space. > > One application that I work on uses floating point math in kernel space, but > it is a constant source of problems - Being forced to migrate to user space > would be a welcome move.. The only question is how much of an overhead does > the trap incur ? The answer probably depends on the machine. You can probably estimate it for x86 by using rdtsc in well chosen places. What you need to measure is the time between the fpu fault in user-space and the beginning of the fpu fault handler in kernel-space, then the time between the end of the fpu fault handler and the return to user-space. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] FPU support
Hi Giles On Tuesday 27 January 2009, Gilles Chanteperdrix wrote: > So, the question is: are there people around who either: > - need FPU support for kernel-space real-time threads; > - do not want to pay the price of a trap when using the FPU in user-space. One application that I work on uses floating point math in kernel space, but it is a constant source of problems - Being forced to migrate to user space would be a welcome move.. The only question is how much of an overhead does the trap incur ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [RFC] FPU support
Hi, having to work on twice consecutive FPU issues made me think a bit about the situation of FPU support in Xenomai. What makes our FPU support code so complex? It is the fact that we support eager FPU context save/restore for both user-space and kernel-space real-time threads which ask it while running side by side with a kernel which supports on-demand FPU for user-space threads. If we only supported on-demand FPU for user-space thread, we could probably get rid of most of the FPU switching code, we would just have to iron Linux FPU trap code (which is already mostly done) and maybe add some code saving the FPU context during the context switches on SMP machines, not a big deal. >From a performance point of view, the difference between on-demand FPU and eager FPU switching is that on-demand FPU switching requires a trap, so you have to pay this overhead once every activation of your real-time task using FPU. Other than that, on-demand FPU actually reduces the dispatch latency of user-space threads not using FPU. So, the question is: are there people around who either: - need FPU support for kernel-space real-time threads; - do not want to pay the price of a trap when using the FPU in user-space. If you are in that case, please answer to this mail. Note that if you do not want everyone to read your answer, you can answer privately. Please also note that this support will not be removed just right now, I really plan to solve the pending issues, and to have an FPU support with no known bugs for the next release. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
