[Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default is doomed to
cause problems for users that run ./configure without looking into each
and every switch - now that CONFIG_SMP is very important for all the
fast locking stuff. Or would the feature check prevent that Xenomai
threads of a non-SMP application are scheduled on multiple CPUs?
However, to improve user experience, let's invert the default.
---
ChangeLog |4
README.INSTALL |2 +-
configure.in |6 +++---
3 files changed, 8 insertions(+), 4 deletions(-)
Index: b/ChangeLog
===
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-08-22 Jan Kiszka [EMAIL PROTECTED]
+
+ * configure.in: Enable SMP support by default.
+
2008-08-21 Philippe Gerum [EMAIL PROTECTED]
* ksrc/nucleus/pipe.c (xnpipe_write): Fix inverted O_SYNC
Index: b/configure.in
===
--- a/configure.in
+++ b/configure.in
@@ -131,12 +131,12 @@ AC_ARG_ENABLE(debug,
esac])
AC_MSG_RESULT(${debug_symbols:-no})
-dnl SMP support (default: off)
+dnl SMP support (default: on)
-CONFIG_SMP=
+CONFIG_SMP=y
AC_MSG_CHECKING(for SMP support)
AC_ARG_ENABLE(smp,
- AS_HELP_STRING([--enable-smp], [Enable SMP support]),
+ AS_HELP_STRING([--disable-smp], [Disable SMP support (if the target
supports it at all)]),
[case $enableval in
y | yes) CONFIG_SMP=y ;;
*) unset CONFIG_SMP ;;
Index: b/README.INSTALL
===
--- a/README.INSTALL
+++ b/README.INSTALL
@@ -143,7 +143,7 @@ NAME DESCRIPTION
--prefix Installation directory /usr/xenomai
--enable-debug Enable debug symbols (-g) disabled
---enable-smp Enable SMP support weak,disabled
+--disable-smpDisable SMP support weak,enabled
1.3.3 Arch-specific configure options
-
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc is hamrless ? LOCK is harmless (except for potential overhead), can't comment isync, but I strongly suspect the same (locking at the glibc e.g.). There is a simple idea behind this: Do you have to install a special glibc in order to enable/disable SMP support? [ BTW, I think the current pthread_mutex implementation lacks the LOCK prefix even in SMP mode due to include issues. Will get fixed with my patches under preparation, which also unifies that stuff on x86. ] Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc is hamrless ? LOCK is harmless (except for potential overhead), can't comment isync, but I strongly suspect the same (locking at the glibc e.g.). There is a simple idea behind this: Do you have to install a special glibc in order to enable/disable SMP support? [ BTW, I think the current pthread_mutex implementation lacks the LOCK prefix even in SMP mode due to include issues. Will get fixed with my patches under preparation, which also unifies that stuff on x86. ] Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP enabled. You mean we should include asm/xenomai/features.h before using CONFIG_SMP ? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc is hamrless ? LOCK is harmless (except for potential overhead), can't comment isync, but I strongly suspect the same (locking at the glibc e.g.). There is a simple idea behind this: Do you have to install a special glibc in order to enable/disable SMP support? [ BTW, I think the current pthread_mutex implementation lacks the LOCK prefix even in SMP mode due to include issues. Will get fixed with my patches under preparation, which also unifies that stuff on x86. ] Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP enabled. You mean we should include asm/xenomai/features.h before using CONFIG_SMP ? That helps as well - I added xeno_config.h explicitly so far, but features.h implies xeno_config.h, of course. Jan - who seems to have run into alignment issues of cmpxchg on x86_64 -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc is hamrless ? LOCK is harmless (except for potential overhead), can't comment isync, but I strongly suspect the same (locking at the glibc e.g.). There is a simple idea behind this: Do you have to install a special glibc in order to enable/disable SMP support? [ BTW, I think the current pthread_mutex implementation lacks the LOCK prefix even in SMP mode due to include issues. Will get fixed with my patches under preparation, which also unifies that stuff on x86. ] Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP enabled. You mean we should include asm/xenomai/features.h before using CONFIG_SMP ? That helps as well - I added xeno_config.h explicitly so far, but features.h implies xeno_config.h, of course. asm/xenomai/features.h does convert the configure.in options into the kernel namespace options. But it seems that CONFIG_SMP is directly set by configure.in anyway. Jan - who seems to have run into alignment issues of cmpxchg on x86_64 pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory used for the mutex. So, if the piece of memory is not eight bytes aligned, this is xnheap_alloc's fault... -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc is hamrless ? LOCK is harmless (except for potential overhead), can't comment isync, but I strongly suspect the same (locking at the glibc e.g.). There is a simple idea behind this: Do you have to install a special glibc in order to enable/disable SMP support? [ BTW, I think the current pthread_mutex implementation lacks the LOCK prefix even in SMP mode due to include issues. Will get fixed with my patches under preparation, which also unifies that stuff on x86. ] Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP enabled. You mean we should include asm/xenomai/features.h before using CONFIG_SMP ? That helps as well - I added xeno_config.h explicitly so far, but features.h implies xeno_config.h, of course. asm/xenomai/features.h does convert the configure.in options into the kernel namespace options. But it seems that CONFIG_SMP is directly set by configure.in anyway. Jan - who seems to have run into alignment issues of cmpxchg on x86_64 pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory used for the mutex. So, if the piece of memory is not eight bytes aligned, this is xnheap_alloc's fault... Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck does this come from? I just thought I only forgot to define it for x86_64, but I don't find any traces for 32-bit as well. Hmm, should this be called CONFIG_XENO_FASTSEM now? Testing... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already)
is
an optimization. In contrast, not enabling it by default is doomed to
cause problems for users that run ./configure without looking into
each
and every switch - now that CONFIG_SMP is very important for all the
fast locking stuff.
I would consider setting CONFIG_SMP by default on x86... because on
some
other architectures like arm, it is not even yet a valid
configuration.
But it is on PowerPC or IA64. Would it cause troubles for the
non-SMP-ready archs? Then we can disable it on those selectively.
Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc
is hamrless ?
LOCK is harmless (except for potential overhead), can't comment isync,
but I strongly suspect the same (locking at the glibc e.g.). There is a
simple idea behind this: Do you have to install a special glibc in order
to enable/disable SMP support?
[ BTW, I think the current pthread_mutex implementation lacks the LOCK
prefix even in SMP mode due to include issues. Will get fixed with my
patches under preparation, which also unifies that stuff on x86. ]
Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP
enabled.
You mean we should include asm/xenomai/features.h before using CONFIG_SMP
?
That helps as well - I added xeno_config.h explicitly so far, but
features.h implies xeno_config.h, of course.
asm/xenomai/features.h does convert the configure.in options into the
kernel namespace options. But it seems that CONFIG_SMP is directly set
by configure.in anyway.
Jan - who seems to have run into alignment issues of cmpxchg on x86_64
pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory
used for the mutex. So, if the piece of memory is not eight bytes
aligned, this is xnheap_alloc's fault...
Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck
does this come from? I just thought I only forgot to define it for
x86_64, but I don't find any traces for 32-bit as well. Hmm, should this
be called CONFIG_XENO_FASTSEM now? Testing...
Yes, XNARCH_HAVE_US_ATOMIC_CMPXCHG is dead now, it was replaced with
CONFIG_XENO_FASTSEM.
CONFIG_XENO_FASTSEM, in turn is set by Kconfig in kernel space, and
configure.in in user-space.
Then this should fix fastsem support again (still preparing the
test...):
---
ksrc/skins/posix/mutex.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: b/ksrc/skins/posix/mutex.c
===
--- a/ksrc/skins/posix/mutex.c
+++ b/ksrc/skins/posix/mutex.c
@@ -97,11 +97,11 @@ int pse51_mutex_init_internal(struct __s
shadow-mutex = mutex;
shadow-lockcnt = 0;
-#ifdef XNARCH_HAVE_US_ATOMIC_CMPXCHG
+#ifdef CONFIG_XENO_FASTSEM
xnarch_atomic_set(shadow-lock, -1);
shadow-attr = *attr;
shadow-owner_offset = xnheap_mapped_offset(sys_ppd-sem_heap, ownerp);
-#endif /* XNARCH_HAVE_US_ATOMIC_CMPXCHG */
+#endif /* CONFIG_XENO_FASTSEM */
if (attr-protocol == PTHREAD_PRIO_INHERIT)
synch_flags |= XNSYNCH_PIP;
@@ -163,16 +163,16 @@ int pthread_mutex_init(pthread_mutex_t *
goto checked;
err = pse51_mutex_check_init(shadow, attr);
-#ifndef XNARCH_HAVE_US_ATOMIC_CMPXCHG
+#ifndef CONFIG_XENO_FASTSEM
cb_read_unlock(shadow-lock, s);
if (err)
return -err;
-#else /* XNARCH_HAVE_US_ATOMIC_CMPXCHG */
+#else /* CONFIG_XENO_FASTSEM */
if (err) {
cb_read_unlock(shadow-lock, s);
return -err;
}
-#endif /* XNARCH_HAVE_US_ATOMIC_CMPXCHG */
+#endif /* CONFIG_XENO_FASTSEM */
checked:
mutex = (pse51_mutex_t *) xnmalloc(sizeof(*mutex));
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Disabling SMP (on platforms where this isn't off by design already) is an optimization. In contrast, not enabling it by default is doomed to cause problems for users that run ./configure without looking into each and every switch - now that CONFIG_SMP is very important for all the fast locking stuff. I would consider setting CONFIG_SMP by default on x86... because on some other architectures like arm, it is not even yet a valid configuration. But it is on PowerPC or IA64. Would it cause troubles for the non-SMP-ready archs? Then we can disable it on those selectively. Are you sure that the lock prefix on an UP x86 or lsync on an UP powerpc is hamrless ? LOCK is harmless (except for potential overhead), can't comment isync, but I strongly suspect the same (locking at the glibc e.g.). There is a simple idea behind this: Do you have to install a special glibc in order to enable/disable SMP support? [ BTW, I think the current pthread_mutex implementation lacks the LOCK prefix even in SMP mode due to include issues. Will get fixed with my patches under preparation, which also unifies that stuff on x86. ] Should be easy to check, disassemble pthread_mutex_lock with CONFIG_SMP enabled. You mean we should include asm/xenomai/features.h before using CONFIG_SMP ? That helps as well - I added xeno_config.h explicitly so far, but features.h implies xeno_config.h, of course. asm/xenomai/features.h does convert the configure.in options into the kernel namespace options. But it seems that CONFIG_SMP is directly set by configure.in anyway. Jan - who seems to have run into alignment issues of cmpxchg on x86_64 pthread_mutex_lock uses xnheap_alloc to allocate the piece of memory used for the mutex. So, if the piece of memory is not eight bytes aligned, this is xnheap_alloc's fault... Maybe it's far simpler: XNARCH_HAVE_US_ATOMIC_CMPXCHG - where the heck does this come from? I just thought I only forgot to define it for x86_64, but I don't find any traces for 32-bit as well. Hmm, should this be called CONFIG_XENO_FASTSEM now? Testing... Yes, XNARCH_HAVE_US_ATOMIC_CMPXCHG is dead now, it was replaced with CONFIG_XENO_FASTSEM. CONFIG_XENO_FASTSEM, in turn is set by Kconfig in kernel space, and configure.in in user-space. Then this should fix fastsem support again (still preparing the test...): Yes, please commit. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
