Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
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: >>> >>> mov0xfffc(%rbp),%ecx >>> mov$0x1,%eax >>> shl%cl,%eax >>> cltq >>> or %rax,0xfff0(%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 PIDPRI PERIOD TIMEOUTTIMEBASE STAT NAME 0 0 -1 0 0 masterR ROOT 0 930 0 0 0 masterR display-928 0 931 99 0 0 masterR sampling-928 [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat CPU PIDMSWCSWPFSTAT %CPU NAME 0 0 0 0 0 00500080 100.0 ROOT 0 9300 0 0 003001880.0 display-928 0 9310 0 0 003001880.0 sampling-928 0 0 0 2070 0.0 IRQ296: [timer] This doesn't happen with !CONFIG_XENO_OPT_SCALABLE_SCHED. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
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: > >>> > >>> mov0xfffc(%rbp),%ecx > >>> mov$0x1,%eax > >>> shl%cl,%eax > >>> cltq > >>> or %rax,0xfff0(%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 PIDPRI PERIOD TIMEOUTTIMEBASE STAT NAME > 0 0 -1 0 0 masterR ROOT > 0 930 0 0 0 masterR display-928 > 0 931 99 0 0 masterR sampling-928 > [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat > CPU PIDMSWCSWPFSTAT %CPU NAME > 0 0 0 0 0 00500080 100.0 ROOT > 0 9300 0 0 003001880.0 display-928 > 0 9310 0 0 003001880.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 2070 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
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
Philippe Gerum wrote: > On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote: > > 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 PIDPRI PERIOD TIMEOUTTIMEBASE STAT NAME > > 0 0 -1 0 0 masterR ROOT > > 0 930 0 0 0 masterR display-928 > > 0 931 99 0 0 masterR > > sampling-928 > > [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat > > CPU PIDMSWCSWPFSTAT %CPU NAME > > 0 0 0 0 0 00500080 100.0 ROOT > > 0 9300 0 0 003001880.0 display-928 > > 0 9310 0 0 003001880.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. ffsmlq uses ffnz, and there are two implementations of ffnz, one in asm/hal.h which is correct on x86_64, the other in nucleus/system.h which uses ffs hence only operates on ints. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote: > > > 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 PIDPRI PERIOD TIMEOUTTIMEBASE STAT NAME > > > 0 0 -1 0 0 masterR ROOT > > > 0 930 0 0 0 masterR > display-928 > > > 0 931 99 0 0 masterR > sampling-928 > > > [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat > > > CPU PIDMSWCSWPFSTAT %CPU NAME > > > 0 0 0 0 0 00500080 100.0 ROOT > > > 0 9300 0 0 003001880.0 display-928 > > > 0 9310 0 0 003001880.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. > > ffsmlq uses ffnz, and there are two implementations of ffnz, one in > asm/hal.h which is correct on x86_64, the other in nucleus/system.h > which uses ffs hence only operates on ints. Never mind, nucleus/system.h is only included when using Xenomai headers in user-space. Nevertheless, it should probably use ffsl instead of ffs. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: > > Philippe Gerum wrote: > > > On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote: > > > > 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 PIDPRI PERIOD TIMEOUTTIMEBASE STAT NAME > > > > 0 0 -1 0 0 masterR ROOT > > > > 0 930 0 0 0 masterR > display-928 > > > > 0 931 99 0 0 masterR > sampling-928 > > > > [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat > > > > CPU PIDMSWCSWPFSTAT %CPU NAME > > > > 0 0 0 0 0 00500080 100.0 ROOT > > > > 0 9300 0 0 003001880.0 display-928 > > > > 0 9310 0 0 003001880.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. > > > > ffsmlq uses ffnz, and there are two implementations of ffnz, one in > > asm/hal.h which is correct on x86_64, the other in nucleus/system.h > > which uses ffs hence only operates on ints. > > Never mind, nucleus/system.h is only included when using Xenomai headers > in user-space. Nevertheless, it should probably use ffsl instead of ffs. > Who the hell is using the ffnz implementation in system.h? The simulator? I kicked it out for a x64-build here, and I got no noticeable effects. signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
Jan Kiszka wrote: > Who the hell is using the ffnz implementation in system.h? The > simulator? I kicked it out for a x64-build here, and I got no noticeable > effects. No, the simulator uses the one in asm-sim/system.h. The one in nucleus/system.h is, for instance, for xnmlqueue_t in user-space. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
On Mon, 2007-04-23 at 14:48 +0200, Jan Kiszka wrote: > Gilles Chanteperdrix wrote: > > Gilles Chanteperdrix wrote: > > > Philippe Gerum wrote: > > > > On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote: > > > > > 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 PIDPRI PERIOD TIMEOUTTIMEBASE STAT NAME > > > > > 0 0 -1 0 0 masterR ROOT > > > > > 0 930 0 0 0 masterR > > display-928 > > > > > 0 931 99 0 0 masterR > > sampling-928 > > > > > [EMAIL PROTECTED] :/root# cat /proc/xenomai/stat > > > > > CPU PIDMSWCSWPFSTAT %CPU NAME > > > > > 0 0 0 0 0 00500080 100.0 ROOT > > > > > 0 9300 0 0 003001880.0 display-928 > > > > > 0 9310 0 0 003001880.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. > > > > > > ffsmlq uses ffnz, and there are two implementations of ffnz, one in > > > asm/hal.h which is correct on x86_64, the other in nucleus/system.h > > > which uses ffs hence only operates on ints. > > > > Never mind, nucleus/system.h is only included when using Xenomai headers > > in user-space. Nevertheless, it should probably use ffsl instead of ffs. > > > > Who the hell is using the ffnz implementation in system.h? The > simulator? I kicked it out for a x64-build here, and I got no noticeable > effects. > No, the simulator uses its own (bugous over 64bit) ffs-based implementation of ffnz. What's in nucleus/system.h is likely a left over from the removed UVM support. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] target width of shifts on 64 bits
Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Who the hell is using the ffnz implementation in system.h? The >> simulator? I kicked it out for a x64-build here, and I got no noticeable >> effects. > > No, the simulator uses the one in asm-sim/system.h. The one in > nucleus/system.h is, for instance, for xnmlqueue_t in user-space. > Thus a removable UVM remainder? At least this ffs/ffsl issue doesn't explain my scheduling problem. signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Fix typo in x86_64 ffnz
Grrr...
Index: include/asm-x86_64/hal.h
===
--- include/asm-x86_64/hal.h(Revision 2402)
+++ include/asm-x86_64/hal.h(Arbeitskopie)
@@ -30,7 +30,7 @@ typedef unsigned long rthal_time_t;
static inline __attribute_const__ unsigned long ffnz(unsigned long ul)
{
- __asm__("bsrq %1, %0":"=r"(ul):"rm"(ul));
+ __asm__("bsfq %1, %0":"=r"(ul):"rm"(ul));
return ul;
}
Index: ChangeLog
===
--- ChangeLog (Revision 2402)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2007-04-23 Jan Kiszka <[EMAIL PROTECTED]>
+
+ * include/asm-x86_64/hal.h (ffnz): Fix typo that inverted the search
+ direction.
+
2007-04-19 Philippe Gerum <[EMAIL PROTECTED]>
* ksrc/skins/vrtx/module.c, ksrc/nucleus/pipe.c,
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] cleanup ffnz from nucleus/system.h
Index: xenomai/ChangeLog
===
--- xenomai.orig/ChangeLog
+++ xenomai/ChangeLog
@@ -3,6 +3,8 @@
* include/asm-x86_64/hal.h (ffnz): Fix typo that inverted the search
direction.
+ * include/nucleus/system.h: Remove unused (and bogus) ffnz wrapper.
+
2007-04-19 Philippe Gerum <[EMAIL PROTECTED]>
* ksrc/skins/vrtx/module.c, ksrc/nucleus/pipe.c,
Index: xenomai/include/nucleus/system.h
===
--- xenomai.orig/include/nucleus/system.h
+++ xenomai/include/nucleus/system.h
@@ -24,11 +24,6 @@
#include
#include
-static inline unsigned long ffnz (unsigned long ul)
-{
-return ffs((int)ul) - 1;
-}
-
#include
#include
#include
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] fix ffnz for 64-bit hosts
I'm just not sure if "#define _GNU_SOURCE" is the preferred way to go.
Index: xenomai/include/asm-sim/system.h
===
--- xenomai.orig/include/asm-sim/system.h
+++ xenomai/include/asm-sim/system.h
@@ -24,6 +24,7 @@
#include
#include
+#define _GNU_SOURCE
#include
#include
#include
@@ -172,7 +173,7 @@ static inline unsigned long long xnarch_
static inline unsigned long ffnz (unsigned long word)
{
-return ffs((int)word) - 1;
+return ffsl(word) - 1;
}
#define xnarch_stack_size(tcb)0
Index: xenomai/ChangeLog
===
--- xenomai.orig/ChangeLog
+++ xenomai/ChangeLog
@@ -5,6 +5,8 @@
* include/nucleus/system.h: Remove unused (and bogus) ffnz wrapper.
+ * include/asm-sim/system.h: Fix ffnz for 64-bit hosts.
+
2007-04-19 Philippe Gerum <[EMAIL PROTECTED]>
* ksrc/skins/vrtx/module.c, ksrc/nucleus/pipe.c,
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
