Jan Kiszka wrote:
Hi,
I just wanted to test how much the worst-cast jitters improve when
running multiple timed threads over the O(1) scheduler instead of the
default one.
It really depends whether your threads actually wake up simultaneously or not.
The scalable scheduler solves the pathological case where your application has
an insane number of threads _actually_ competing for the current CPU, i.e. all
being in a runnable state at the same time or within a short window of time. IOW,
it implements O(1) for the ready queue. We don't use any sequential access for the
suspended thread queue, and beyond that, I'm even going to kill the latter since
it's actually useless.
Unfortunately, it already crashes my box with the standard
latency test. All debug stuff on and serial console attached still does
not give any output. Looks like a really fatal scheduler crash. :(
Anyone any ideas?
It breaks with the development trunk/ because we are extending the ability of
the core pod to provide a larger priority scale, so that we can provide
VxWorks et al. with a native syscall interface. The new scale likely messes up
with the priority bitmaps used in the scalable sched. Will fix.
Jan
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
