[Xenomai-core] T_FPU without effect

[Xenomai-core] T_FPU without effect

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

Hi,

after receiving SIGXCPU for unexpected context switches in a larger
application, I found out that the T_FPU bit does not seem to be
recognised on x86 during native task creation. Here is a simple test
case, watch out for /proc/xenomai/faults after program start and 5 s later:

#include <native/task.h>
#include <sys/mman.h>

float x;

void task_func(void *p)
{
    rt_task_sleep(5000000000LL);
    x = 3.14 + (int)p;
}

main()
{
    RT_TASK task;

    mlockall(MCL_CURRENT|MCL_FUTURE);

    rt_task_spawn(&task, NULL, 0, 40, T_FPU | T_JOINABLE, task_func, 0);
    rt_task_join(&task);

    return 0;
}


Any immediate ideas?

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] T_FPU without effect

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Hi,
 > 
 > after receiving SIGXCPU for unexpected context switches in a larger
 > application, I found out that the T_FPU bit does not seem to be
 > recognised on x86 during native task creation. Here is a simple test
 > case, watch out for /proc/xenomai/faults after program start and 5 s later:
 > 
 > #include <native/task.h>
 > #include <sys/mman.h>
 > 
 > float x;
 > 
 > void task_func(void *p)
 > {
 >     rt_task_sleep(5000000000LL);
 >     x = 3.14 + (int)p;
 > }
 > 
 > main()
 > {
 >     RT_TASK task;
 > 
 >     mlockall(MCL_CURRENT|MCL_FUTURE);
 > 
 >     rt_task_spawn(&task, NULL, 0, 40, T_FPU | T_JOINABLE, task_func, 0);
 >     rt_task_join(&task);
 > 
 >     return 0;
 > }
 > 
 > 
 > Any immediate ideas?

User-space threads always have the FPU bit anyway. When a user-space
thread in primary mode uses FPU for the first time on x86, the FPU
hardware is initialized in the fault handler, this is the expected
behaviour. This allow the nucleus to not switch FPU context for
user-space threads that never use the FPU.

In case of an abnormal FPU fault, the message "invalid use of FPU" is
printed on console.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] T_FPU without effect

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi,
>  > 
>  > after receiving SIGXCPU for unexpected context switches in a larger
>  > application, I found out that the T_FPU bit does not seem to be
>  > recognised on x86 during native task creation. Here is a simple test
>  > case, watch out for /proc/xenomai/faults after program start and 5 s later:
>  > 
>  > #include <native/task.h>
>  > #include <sys/mman.h>
>  > 
>  > float x;
>  > 
>  > void task_func(void *p)
>  > {
>  >     rt_task_sleep(5000000000LL);
>  >     x = 3.14 + (int)p;
>  > }
>  > 
>  > main()
>  > {
>  >     RT_TASK task;
>  > 
>  >     mlockall(MCL_CURRENT|MCL_FUTURE);
>  > 
>  >     rt_task_spawn(&task, NULL, 0, 40, T_FPU | T_JOINABLE, task_func, 0);
>  >     rt_task_join(&task);
>  > 
>  >     return 0;
>  > }
>  > 
>  > 
>  > Any immediate ideas?
> 
> User-space threads always have the FPU bit anyway. When a user-space

Yep, I stumbled over this fact meanwhile.

> thread in primary mode uses FPU for the first time on x86, the FPU
> hardware is initialized in the fault handler, this is the expected
> behaviour. This allow the nucleus to not switch FPU context for
> user-space threads that never use the FPU.

But doesn't this lazy scheme introduce the risk of unexpected latencies
for the first FPU usage of a RT task? I mean, there is already the
information available if a task is going to use the FPU (via the flag),
then why not make use of it?

> 
> In case of an abnormal FPU fault, the message "invalid use of FPU" is
> printed on console.
> 

Yeah, I got this unfortunately only once: full alarm, both via kernel
message and SIGXCPU. So far I failed to reproduce it. I tested that
"normal" FPU usage for the first time does not trigger that warnings.
What may have caused this?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] T_FPU without effect

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > > thread in primary mode uses FPU for the first time on x86, the FPU
 > > hardware is initialized in the fault handler, this is the expected
 > > behaviour. This allow the nucleus to not switch FPU context for
 > > user-space threads that never use the FPU.
 > 
 > But doesn't this lazy scheme introduce the risk of unexpected latencies
 > for the first FPU usage of a RT task?

It does.

 > I mean, there is already the
 > information available if a task is going to use the FPU (via the flag),
 > then why not make use of it?

In the current situation, all user-space tasks have the XNFPU bit set,
because non real-time user-space tasks (including user-space real-time
tasks in secondary mode) may be preempted at a point where their FPU
context was used, so it must be switched when switching to another task
that has the XNFPU bit set. At nucleus level, FPU is switched
eagerly. At the lower, architecture dependent, level, where the XNFPU
bit is not available, switches for the user-space tasks that never used
FPU are avoided, at least for the x86 architecture.

What we could imagine, is to allow shadows to set or not the XNFPU bit,
meaning that the task would be allowed to use the FPU in primary mode,
whereas in secondary mode, it would always be allowed to use it. The
initialization of the FPU context would take place in xnshadow_map if
the XNFPU bit is set. But is it really meaningful for a task that is
always allowed to use FPU in secondary mode to be forbidden to use it in
primary mode ?

Besides, before such a change, I think we should improve the testsuite
by adding some context switching test, with an optional FPU switching
test. This is something I would like to do, once I get latency -t 1 to
work on SMP, I mean.

 > 
 > > 
 > > In case of an abnormal FPU fault, the message "invalid use of FPU" is
 > > printed on console.
 > > 
 > 
 > Yeah, I got this unfortunately only once: full alarm, both via kernel
 > message and SIGXCPU. So far I failed to reproduce it. I tested that
 > "normal" FPU usage for the first time does not trigger that warnings.
 > What may have caused this?

If a kernel task use the FPU without the XNFPU bit set, this error is
triggered. Every time this error was triggered in other cases, as of
today, there was a real bug.

-- 


					    Gilles Chanteperdrix.