Re: [Xenomai-core] O(1) scheduler broken

[Philippe Gerum <rpm@xenomai.org>]

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.