On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Philippe Gerum wrote:
> >> On Wed, 2007-04-18 at 20:13 +0200, Jan Kiszka wrote:
> >>> Hi Philippe,
> >>>
> >>> here is an explanation of the scalable scheduler issue I face on x86_64
> >>> under different gcc compilers:
> >>>
> >>>         unsigned long x = 0;
> >>>         int n = 32;
> >>>
> >>>         x |= 1 << n;
> >>>
> >>> The last instruction translates to:
> >>>
> >>>   mov    0xfffffffffffffffc(%rbp),%ecx
> >>>   mov    $0x1,%eax
> >>>   shl    %cl,%eax
> >>>   cltq
> >>>   or     %rax,0xfffffffffffffff0(%rbp)
> >>>
> >> Blast. Good spot.
> >>
> >>> That means we only shift with 32-bit precision although the target type
> >>> is 64 bit. We find such code for setting the queue usage bits in
> >>> addmlq(), but probably elsewhere too. This variant lets gcc generate the
> >>> desired code:
> >>>
> >>>   x |= (unsigned long)1 << n;
> >>>
> >>> Compiler issue, x86_64-specific oddity, or generic 64-bit problem we may
> >>> have across the ipipe and Xenomai code (ppc64, ia64?)?
> >>>
> >> A brief look at the I-pipe code base shows that most shift expressions
> >> have righthand sides limited to small values (at least always < 32), and
> >> when they don't, the lefthand side is properly cast to long long values,
> >> so this should be ok.
> >>
> >> BUT, it's a general 64bit port issue for Xenomai, which is not specific
> >> to the multi-level queue implementation. We have the same issue going on
> >> with at least:
> >>
> >> - the posix registry
> >> - the message pipe support from the nucleus
> >> - the vrtx id generator
> >>
> >> Gentlemen, it's time for bug hunting.
> >>
> >>> After patching nucleus/queue.h appropriately, my oopses disappear, but
> >>> RT threads still do not run (no CSW to the threads latency creates).
> >>> Jan
> >>>
> >>>
> >>> PS: If you are interested, I could post a modified qemu patch that
> >>> enables gdb kernel debugging under x86_64.
> >>>
> >> Yes please. I would have a look to the remaining issue I have here
> >> exclusively over qemu, which seems unrelated to the multi-level queue
> >> issue though.
> >>
> > 
> > Attached. A post to qemu-devel is also on the way. I wonder way the
> > original patch by Jason Wessel, posted last September, or a variant of
> > it still didn't make it into a qemu release or at least its CVS. Anyway.
> > 
> 
> A few iteration later, a new version of my qemu patch (now with more
> registers...):
> 
> http://article.gmane.org/gmane.comp.emulators.qemu/17315
> 
> 
> BTW, with latest SVN trunk and scalable sched, the oopses are gone but
> latency still doesn't start up:
> 
> [EMAIL PROTECTED] :/root# cat /proc/xenomai/sched 
> CPU  PID    PRI      PERIOD     TIMEOUT    TIMEBASE  STAT       NAME
>   0  0       -1      0          0          master    R          ROOT
>   0  930      0      0          0          master    R          display-928
>   0  931     99      0          0          master    R          sampling-928
> [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat  
> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>   0  0      0          0          0     00500080  100.0  ROOT
>   0  930    0          0          0     00300188    0.0  display-928
>   0  931    0          0          0     00300188    0.0  sampling-928

Two threads in ready state with higher priority than the root one: this
means that a rescheduling opportunity has been missed, or more
precisely, someone may be lying to xnpod_schedule() wrt to priority
ordering when the scalable sched is enabled.

>   0  0      0          207        0     00000000    0.0  IRQ296: [timer]
> 
> This doesn't happen with !CONFIG_XENO_OPT_SCALABLE_SCHED.
> 
> Jan
> 
-- 
Philippe.



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

Reply via email to