All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Heikki Lindholm <holindho@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] [rfc] unit testing context switches.
Date: Sun, 4 Jun 2006 14:58:13 +0200	[thread overview]
Message-ID: <17538.55525.494004.44221@domain.hid> (raw)
In-Reply-To: <4481EE11.9040109@domain.hid>

Heikki Lindholm wrote:
 > Yes, Altivec is separate from the FPU. Hopefully nobody uses FPU in the 
 > kernel - AFAIK currently not, but you never know about closed-source 
 > drivers and such. Whereas, Altivec, I think, is something that should, 
 > eventually, be supported by the real-time domain, too. Adding Altivec 
 > support is very similar to the existing fpu support, and being that it 
 > has to tackle the kernel-using-altivec issue anyway, it's probably nicer 
 > to add fpu kernel support as well. Only problem is that it will increase 
 > the context switch time. 

Maybe we could add an XNSIMD flag for Altivec and SSE, distinct from
XNFPU, so that only the task that really use SIMD instructions would pay
the price of the switch ?

 > I'd remember that using the FPU bits (instead 
 > of task state) from the processor will pretty much cause saving state on 
 > every transition to xeno, because of the kernel's lazy usage model (on 
 > UP; SMP will do that anyway).

I do not understand what you mean: on x86 the state of the ts bit in cr0
is enough to know if the FPU was used either in kernel-space or in
user-space. I know power pc is a bit different because the state of the
FPU is saved by the user/kernel switches, but is not the state of the
MSR_FP bit enough to know if FPU was used in kernel-space ?

-- 


					    Gilles Chanteperdrix.


  reply	other threads:[~2006-06-04 12:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-02 20:20 [Xenomai-core] [rfc] unit testing context switches Gilles Chanteperdrix
2006-06-02 23:50 ` Jim Cromie
2006-06-03  7:13 ` Heikki Lindholm
2006-06-03 16:46   ` Gilles Chanteperdrix
2006-06-03 17:26     ` Gilles Chanteperdrix
2006-06-03 20:16       ` Heikki Lindholm
2006-06-04 12:58         ` Gilles Chanteperdrix [this message]
2006-06-04 13:47           ` Heikki Lindholm
2006-06-04 17:48             ` Gilles Chanteperdrix
2006-06-04 18:19               ` Heikki Lindholm
2006-06-03  8:04 ` Jan Kiszka
2006-06-07 18:00 ` Gilles Chanteperdrix
2006-06-07 18:25   ` Jan Kiszka
2006-06-07 18:30   ` Philippe Gerum
2006-06-07 18:42   ` Jan Kiszka
2006-06-08 12:28     ` Gilles Chanteperdrix
2006-06-08 17:35       ` Heikki Lindholm
2006-06-08 18:42         ` Gilles Chanteperdrix
2006-06-08 19:27           ` Heikki Lindholm
2006-06-08 20:44             ` 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=17538.55525.494004.44221@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=holindho@domain.hid \
    --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.