[Xenomai-core] O(1) scheduler broken

[Xenomai-core] O(1) scheduler broken

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

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. 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?
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Philippe Gerum]

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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

Philippe Gerum wrote:
> 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 {
> 

Cute :), but it works. Thanks.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]