On 02/06/2013 06:40 PM, Jan Kiszka wrote:
> On 2013-02-06 18:35, Gilles Chanteperdrix wrote:
>> On 02/06/2013 06:33 PM, Jan Kiszka wrote:
>>
>>> On 2013-02-06 18:09, Gilles Chanteperdrix wrote:
>>>> On 02/06/2013 06:03 PM, Jan Kiszka wrote:
>>>>
>>>>> Gilles,
>>>>>
>>>>> do you remember if this core-3.4 change was a performance optimization
>>>>> or a necessary fix? Also, I'm not yet understanding why we need all the
>>>>> #ifdefs except for the first one which forces fpu.preload to 0.
>>>>
>>>>
>>>> It is a performance optimization, without it, we systematically hit the
>>>> maximum latency when the timer would tick during a context switch which
>>>> restores the FPU. Note that if you change that, you will probably break
>>>> -forge.
>>>
>>> According to the Intel folks who introduced eagerfpu, xsave, or at least
>>> xsaveopt (which I didn't implemented yet) is now faster than serializing
>>> clts/stts. On the other hand, the worst case is a full SSE + AVX restore
>>> while the target RT task is not depending on the FPU.
>>
>>
>> Without xsave, we never restore fpu if the RT task never used it. This
>> changes with xsave?
>
> This would change with eagerfpu which depends on xsave. The kernel
> sticks with lazy switching in the absence of xsaveopt.
I am not sure you understand what I mean, so, I am going to reformulate.
Without xsave, Linux uses lazy fpu restore, and Xenomai uses eager fpu
restore. But Xenomai eager fpu restore is a nop if the RT task never
used FPU since its inception (and all the parents from which it is
cloned never used FPU either). Does Linux eager switching mean the same
thing?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
