> What are you comparing, I mean, exactly?
> All kernel RTAI vs all userland Xenomai?

Yes.

>
>
> The timer handler is charged for the callbacks it runs, so it really
> boils down to what code is attached to Xenomai timers, aside of the
> built-in scheduler tick.

In this case we have only a single RTDM timer that fires ever 125 us  
and does nothing (as a test.) It will be easy to remove this and  
compare the amount of usage irq0 handler uses without it. I know it'll  
be at least 14 or 15.

>
>
> When you measure that load, what does /proc/xenomai/timerstat say?
>
>> I know
>> there is some overhead with userspace calls but hte irq0 handler  
>> alone
>> accounts for 20% of it. Are there any options that can speed things  
>> up?
>>
>
> Yeah, but you won't like it: buy a Geode that has SEP support for
> syscalls and a working TSC, then switch on --enable-x86-sep. Ok,
> granted, that is _not_ funny.

We have a new Geode that has SEP and yes, things are faster. Just how  
much overhead does syscall create? Is there no better option other  
than SEP? If we could have kernel threads work without corrupting  
userland FPU contexts then we could use our two higher priority  
drivers in a kernel module to save overhead.

Is TSC really going to make that much of a difference? It seems that  
xenomai uses PIT anyway. We can build with TSC if we disable suspend  
on halt and it works. If we do this the usage stays the same. It may  
drop a couple tenths of a percent.

> What would be interesting is to get the value reported for the timer
> interrupt when the standard latency test runs at the same frequency  
> than
> your application does (use -p option).

So you mean look at cat /proc/stat/xenomai while running latency test - 
p?

Steven


_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to