Re: [Xenomai] ipipe/x86: do not restore during context switch

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 02/06/2013 06:47 PM, Jan Kiszka wrote:

> On 2013-02-06 18:44, Gilles Chanteperdrix wrote:
>> 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?
> 
> eagerfpu means: always call xsaveopt/xrstor, it will optimize the case
> that the FPU was unused by the source/destination. And no fiddling with
> TS anymore, at no time.


I still do not understand this sentence then: "the worst case is a full
SSE + AVX restore while the target RT task is not depending on the FPU."
If the RT task does not depend on the FPU, why would xsaveopt/xrstor
restore SSE and AVX context?

-- 
                                                                Gilles.