All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] T_FPU without effect
Date: Sat, 15 Apr 2006 11:49:16 +0200	[thread overview]
Message-ID: <4440C19C.2000302@domain.hid> (raw)
In-Reply-To: <17471.42250.270559.782396@domain.hid>

[-- 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 --]

  reply	other threads:[~2006-04-15  9:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-14  8:31 [Xenomai-core] T_FPU without effect Jan Kiszka
2006-04-14 13:35 ` Gilles Chanteperdrix
2006-04-15  9:49   ` Jan Kiszka [this message]
2006-04-15 15:02     ` Gilles Chanteperdrix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4440C19C.2000302@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.