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: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to