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?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
