From: eliot@cincom.com
To: ak@muc.de
Cc: linux-kernel@vger.kernel.org, tgriggs@key.net
Subject: Re: PROBLEM: 2.6 kernels on x86 do not preserve FPU flags across context switches
Date: Wed, 16 Jun 2004 16:01:46 -0700 [thread overview]
Message-ID: <200406162302.QAA01806@central.parcplace.com> (raw)
Hi Andi,
you asked:
| On what CPUs does the failure occur? Linux uses different paths
| depending on if the CPU supports SSE or not.
Travis responded:
| We run on both AMDs (Durons and Athlons) as well as PII, PIII, and
| PIV's. Our kernels are all compiled as generic 586+. Though when we were
| testing for this, we did try the more generic 486+ option, as well as
| exact processor matches for the AMD at least. I don't remember it making
| a difference.
+-----------------------------
| Date: Wed, 16 Jun 2004 23:40:18 +0200
| From: Andi Kleen <ak@muc.de>
| Subject: Re: PROBLEM: 2.6 kernels on x86 do not preserve FPU flags across context switches
| eliot@cincom.com writes:
| > 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
| Funny, Linux just added fnclex to a critical path on popular request.
| But I guess it will need to be removed again, we already discussed
| that.
| > 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.
| This sounds like a serious kernel bug that should be fixed if
| true. Can you perhaps create a simple demo program that shows the
| problem and post it?
| On what CPUs does the failure occur? Linux uses different paths
| depending on if the CPU supports SSE or not.
| Does your program receive signals? Could it be related to them?
| -Andi
---
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
next reply other threads:[~2004-06-16 23:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-16 23:01 eliot [this message]
2004-06-17 10:35 ` PROBLEM: 2.6 kernels on x86 do not preserve FPU flags across context switches Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2004-06-16 22:26 eliot
2004-06-17 10:39 ` Andi Kleen
[not found] <27Pmy-sO-25@gated-at.bofh.it>
2004-06-16 21:40 ` Andi Kleen
2004-06-16 20:32 eliot
2004-06-16 21:03 ` Richard B. Johnson
2004-06-17 6:43 ` Denis Vlasenko
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=200406162302.QAA01806@central.parcplace.com \
--to=eliot@cincom.com \
--cc=ak@muc.de \
--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