Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: "Atsushi Nemoto" <anemo@mba.ocn.ne.jp>, <linux-mips@linux-mips.org>
Subject: Re: preempt safe fpu-emulator
Date: Thu, 28 Apr 2005 18:06:53 +0200	[thread overview]
Message-ID: <004e01c54c0c$4c9f3d30$10eca8c0@grendel> (raw)
In-Reply-To: 20050428152123.GH1276@linux-mips.org

> On Thu, Apr 28, 2005 at 06:58:28AM -0700, Kevin D. Kissell wrote:
> 
> > When I first integrated the Algorithmics emulator with the Linux kernel
> > several years back, I tried doing something like this but ran into some
> > problem that I cannot recall exactly - there may have been some case
> > where the system expected threads to "inherit" FCSR changes.  I agree
> > that this is an obviously cleaner approach, but be careful.
> 
> The global variables definately won't fly anymore in preemptable and SMP
> kernels.  Or rather any attempt to get that to work would only make things
> worse, so they had to go.

The global variable thing was clearly not SMP safe - but then again, the
32-bit MIPS kernel we were working with wasn't SMP safe either, in
those days.  ;o)  But *if* - and it may not really (or no longer) be the case - 
there is an implicit assumption that some FCSR state is preserved on a
context switch, it would be more correct to map the ieee754_csr symbol
to a per-CPU variable than a per-thread variable.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, linux-mips@linux-mips.org
Subject: Re: preempt safe fpu-emulator
Date: Thu, 28 Apr 2005 18:06:53 +0200	[thread overview]
Message-ID: <004e01c54c0c$4c9f3d30$10eca8c0@grendel> (raw)
Message-ID: <20050428160653.4hbp9zA21rt1C9IXASMcjSUBbkpPcUk_RcVtOH3HAg4@z> (raw)
In-Reply-To: 20050428152123.GH1276@linux-mips.org

> On Thu, Apr 28, 2005 at 06:58:28AM -0700, Kevin D. Kissell wrote:
> 
> > When I first integrated the Algorithmics emulator with the Linux kernel
> > several years back, I tried doing something like this but ran into some
> > problem that I cannot recall exactly - there may have been some case
> > where the system expected threads to "inherit" FCSR changes.  I agree
> > that this is an obviously cleaner approach, but be careful.
> 
> The global variables definately won't fly anymore in preemptable and SMP
> kernels.  Or rather any attempt to get that to work would only make things
> worse, so they had to go.

The global variable thing was clearly not SMP safe - but then again, the
32-bit MIPS kernel we were working with wasn't SMP safe either, in
those days.  ;o)  But *if* - and it may not really (or no longer) be the case - 
there is an implicit assumption that some FCSR state is preserved on a
context switch, it would be more correct to map the ieee754_csr symbol
to a per-CPU variable than a per-thread variable.

            Regards,

            Kevin K.

  parent reply	other threads:[~2005-04-28 16:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-27  5:36 preempt safe fpu-emulator Atsushi Nemoto
2005-04-27  5:46 ` Atsushi Nemoto
2005-04-27 10:49   ` New Forum for support of RB500 (MIPS board) John Tully
2005-04-28 13:41 ` preempt safe fpu-emulator Ralf Baechle
2005-04-28 13:58   ` Kevin D. Kissell
2005-04-28 13:58     ` Kevin D. Kissell
2005-04-28 15:21     ` Ralf Baechle
2005-04-28 15:25       ` Maciej W. Rozycki
2005-04-28 15:33         ` Ralf Baechle
2005-04-28 15:34           ` Ralf Baechle
2005-04-28 16:06       ` Kevin D. Kissell [this message]
2005-04-28 16:06         ` Kevin D. Kissell
2005-04-29 13:40         ` Atsushi Nemoto
2005-04-30 14:36   ` Atsushi Nemoto

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='004e01c54c0c$4c9f3d30$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox