> What are you comparing, I mean, exactly?
> All kernel RTAI vs all userland Xenomai?
> 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
>> accounts for 20% of it. Are there any options that can speed things
> 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
> your application does (use -p option).
So you mean look at cat /proc/stat/xenomai while running latency test -
Xenomai-core mailing list