[Xenomai-core] [RFC] FPU support

[Xenomai-core] [RFC] FPU support

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] [RFC] FPU support

[Paul]

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.

Re: [Xenomai-core] [RFC] FPU support

[Gilles Chanteperdrix]

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.

Re: [Xenomai-core] [RFC] FPU support

[Philippe Gerum]

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.

Re: [Xenomai-core] [Xenomai-help] [RFC] FPU support

[Wolfgang Denk]

Dear Gilles Chanteperdrix,

In message <497F6524.2080601@domain.hid> you 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.

My gut feeling (and this is all I can offer at this point) is that
there will probably be only very few (but still some) people inthe
first group, but a larger number of users in the second group.
Especially on smaller embedded processors taking a trap is a penalty
you usually want to avoid.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
In C we had to code our own bugs, in C++ we can inherit them.

Re: [Xenomai-help] [Xenomai-core] [RFC] FPU support

[Steven Seeger]

We are using FPU support in one kernel space thread to generate tones
with a DDS algorithm via an ioctl in a xenomai software sound driver. 
Steven