maintaining 3.xes

Paolo Mantegazza mantegazza at
Wed Oct 6 10:39:09 CEST 2004

Rus V. Brushkoff wrote:
> On Tue, 5 Oct 2004, Paolo Mantegazza wrote:
> 	Hi.
> :has been ported to a single non x86 architecture, I will dismiss support
> :for all kernel only schedulers: sched_up/mup/smp. They are of no use
> :anymore on x86 already, users of such an architecture should concentrate
> :on LXRT immediately. Recall that it does not mean you'll have to abandon
>  Does this mean that latency for kernel scheduler driven app and LXRT
> one has become equal ?
> Last time (half year ago though) I measured latency, the LXRT scheduler
> gave me twice big numbers compared to kernel variant ;(

There have been tests running for days to check 3.1 and I know the above 
is true only for short times under no load. With only moderate activity 
after a hour there is no difference.

In any case if you used RTAI as it was you were using kernel threads for 
kernel space and they make a difference since they require a longer 
switch time than RTAI proper kernel tasks used in legacy kernel only 
schedulers. However, down to old plain Pentiums, the switching time is a 
small part of the latency build up. So overall there is no difference.

In any case LXRT can work with RTAI proper kernel tasks also. You have 
simply to enable the macro USER_RTAI_TASKS and you'll work as with any 
legacy kernel only schedulers application. With that done if there is 
any difference than it is black magic :-).

So, as I said, there is nothing lost in using LXRT only, the only 
problem at the moment being that it is just for x86. That's why I said I 
will keep legacy stuff till it is not verified for another architecture, 
so that we can be sure that it is structured in a really neutral way.

In any case users will notice nothing as they'll always find also the 
same rtai_up module they use now, but it will be built on sched_lxrt 
LXRT, with RTAI proper kernel tasks enabled, and not on sched_up.


More information about the Rtai mailing list