public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: eliot@cincom.com
To: linux-kernel@vger.kernel.org
Cc: tgriggs@key.net, eliot@cincom.com
Subject: PROBLEM: 2.6 kernels on x86 do not preserve FPU flags across context switches
Date: Wed, 16 Jun 2004 13:32:24 -0700	[thread overview]
Message-ID: <200406162032.NAA29397@central.parcplace.com> (raw)

Hi,

	I am the team lead and chief VM developer for a Smaltalk implementation based on a JIT execution engine.  Our customers have been seeing rare incorrect floating-point results in intensive fp applications on 2.6 kernels using various x86 compatible processors.  These problems do not occur on previous kernel versons.  We recently had occasion to reimplement our fp primitives to avoid severe performance problems on Xeon processors that were traced to Xeon's relatively slow implementation of fnclex and fstsw.  The older implementaton would produce a result and test for a valid (non NaN, non Inf) result by examining the FPU status flags via fstsw.  The newer implementation produces a result and tests its exponent for the NaN/Inf exponent.  The new implementation does not show the rare incorrect floating-point results in intensive fp applications on 2.6 kernels.  My conclusion is that context switches between the production of the result and the execution of the fstsw are the culprit, and that the context switch machinery fails to preserve the FPU status flags.

I don't know whether any action on your part is appropriate.  The use of the FPU status flags is presumably rare on linux (I believe that neither gcc nor glibc make use of them).  But "exotic" execution machinery such as runtimes for dynamic or functional languages (language implementations that may not use IEEE arithmetic and instead flag Infs and NaNs as an error) may fall foul of this issue.  Since previous versions of the kernel on x86 apparently do preserve the FPU status flags perhaps its simple to preserve the old behaviour.  At the very least let me suggest you document the limitation.

Sincerely,
---
Eliot Miranda                 ,,,^..^,,,                mailto:eliot@cincom.com
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500



             reply	other threads:[~2004-06-16 20:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-16 20:32 eliot [this message]
2004-06-16 21:03 ` PROBLEM: 2.6 kernels on x86 do not preserve FPU flags across context switches Richard B. Johnson
2004-06-17  6:43   ` Denis Vlasenko
     [not found] <27Pmy-sO-25@gated-at.bofh.it>
2004-06-16 21:40 ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-06-16 22:26 eliot
2004-06-17 10:39 ` Andi Kleen
2004-06-16 23:01 eliot
2004-06-17 10:35 ` Andi Kleen

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=200406162032.NAA29397@central.parcplace.com \
    --to=eliot@cincom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tgriggs@key.net \
    /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