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

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

On 02/06/2013 09:17 PM, Jan Kiszka wrote:

> On 2013-02-06 21:03, Gilles Chanteperdrix wrote:
>> On 02/06/2013 08:55 PM, Jan Kiszka wrote:
>>
>>>> To the contrary, the overhead is the cost of the fault (with the
>>>> user/kernel and kernel/user switches), so, the larger the context
>>>> switch, the smaller the overhead in proportion.
>>>
>>> Yes, continuously faulting in FPU states of heavy Linux users is the
>>> problem. That must be changed.
>>
>>
>> We are talking x86 here, so, the cost of the FPU fault is not that heavy.
>>
>>>>> Instead of always doing stts for the new task, we could do the restore
>>>>> later, after the hard_local_irq_enable of __ipipe_switch_tail. That
>>>>> should allow the eager model for Linux as well without making
>>>>> save+restore of Linux-Linux switches atomic.
>>>>
>>>>
>>>> That could be done, but it is probably simpler to implement unlocked
>>>> context switch, and split __switch_to into several atomic sections.
>>>
>>> Yep, indeed.
>>>
>>>> Anyway, any change in this area will probably break the work done for
>>>> kthreads on -forge, so, can't we postpone this?
>>>
>>> For how long? What are the dependencies?
>>
>>
>> For the time it takes to validate FPU on kthreads with -forge.
>>
>>> I thought unlocked context
>>> switches already exit for other archs.
>>
>>
>> That is not an issue, indeed.
>>
>>>
>>> At least I will need to look into this internally - we are using less
>>> than 10% of our CPUs for RT, the rest wants high performance.
>>
>>
>> Are you sure this is not a priori optimization of something which is not
>> really an issue?
> 
> Of course, it depends on the context switch rate. We have to measure,
> but I wouldn't be surprised to see high numbers. And the FPU is used by
> everything today.
> 
> My colleague recently measured that (on an older standard kernel)
> accelerated disk encryption was slightly slower than unaccelerated one -
> due to the overhead of FPU context switches. I suppose we have a nice
> benchmark in that scenario (dd on an encrypted disk)...


You are talking kernel_fpu_begin()/kernel_fpu_end() here, this is a
completely different issue. If Xenomai interrupts Linux in the middle of
such a section, the FPU context is restored eagerly when switching back
to Linux, so there is absolutely nothing more we can do in this area.

-- 
                                                                Gilles.