All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Elie <phil.el@wanadoo.fr>
To: paubert <paubert@iram.es>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>, Andi Kleen <ak@suse.de>,
	David Mosberger <davidm@hpl.hp.com>
Subject: Re: [PATCH] Mask mxcsr according to cpu features.
Date: Fri, 09 May 2003 21:00:46 +0000	[thread overview]
Message-ID: <3EBC16FE.506@wanadoo.fr> (raw)
In-Reply-To: 20030509165051.A31465@mrt-lx16.iram.es

paubert wrote:
> On Fri, May 09, 2003 at 04:33:37PM +0000, Philippe Elie wrote:

>>The only problem we can get is an old processor which write non
>>zero but random bits in the 16 upper bits.
> 
> 
> I don't believe that there is any, but that maybe some which don't
> write anything, hence the requirement for clearing the area in the
> DAZ detection algorithm.

right


>>my documentation says to fxsave and get the features mask from
>>the mxcsr mask but to fall back to 0xffbf if mask == 0, quoting
>>docs 11.6.6:
>>
>>1 setup a fxsave area
>>2 clear this area
>>3 fxsave in this area
>>4 if mxcsr == 0 use mask 0xffbf else use mxcsr mask
> 
> 
> Too expensive unless the mask is computed at boot time once and for 

yeps,

> all (thrashing half a kB  for a single 32 bit constant, sigh). I did 

uh? you just need to fxsave on stack, extract the mask, the struct
is 512 bytes length, surely during kernel init 512 bytes stack
allocation is right

> not want to touch too many files in my patch, but it seems unavoidable. 


> Now a last question, are there SMP systems in which one processor
> supports DAZ and the other does not, just to complicate matters a
> little more?

Such system are not symetric. I don't think we must take care
about this theorical things and I'm pretty sure than mixing old
P4 and newers in a box can't work. Anyway even if it works
userspace program using DAZ will be not reliable since they can
run from time to time on cpu with DAZ then cpu w/o DAZ.

regards,
Phil



  reply	other threads:[~2003-05-09 18:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-09  0:42 [PATCH] Mask mxcsr according to cpu features paubert
2003-05-09  2:24 ` Andi Kleen
2003-05-09 10:56   ` paubert
2003-05-09 11:41     ` Andi Kleen
2003-05-09  6:32 ` Philippe Elie
2003-05-09 10:48   ` paubert
2003-05-09 16:33     ` Philippe Elie
2003-05-09 16:50       ` paubert
2003-05-09 21:00         ` Philippe Elie [this message]
2003-05-11 23:31           ` [PATCH] [CFT] [RFC] Correct mxcsr handling (was: Mask mxcsr according to cpu features.) Gabriel Paubert

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=3EBC16FE.506@wanadoo.fr \
    --to=phil.el@wanadoo.fr \
    --cc=ak@suse.de \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paubert@iram.es \
    --cc=torvalds@transmeta.com \
    /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.