Philippe Gerum wrote:
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.
This should fix the current issue.
--- include/nucleus/queue.h (revision 741)
+++ include/nucleus/queue.h (working copy)
@@ -580,7 +580,7 @@
/* Multi-level priority queue */
-#define XNSPQUEUE_PRIOS (XNCORE_MAX_PRIO + 1)
+#define XNSPQUEUE_PRIOS (XNCORE_MAX_PRIO + 2)
#define XNSPQUEUE_BITMAPSIZE ((XNSPQUEUE_PRIOS + BITS_PER_LONG - 1) /
BITS_PER_LONG)
typedef struct xnspqueue {
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
