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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:31 EST