Skip to contentSkip to conversation

userspace: Make CONFIG_SMP default

PATCH In review Jan Kiszka 2 participants 12 messages Aug 22, 2008

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 1/1 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(-)
ChangeLog +4 -0
Index: 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
configure.in +3 -3
Index: 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 ;;
README.INSTALL +1 -1
Index: 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-smp        Disable SMP support             weak,enabled
 
 1.3.3 Arch-specific configure options
 -------------------------------------
#1 lore raw
Quoted 5 lines · Jan Kiszka

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.

Signature · 1 line
                                                 Gilles.
author
#2 lore raw
Quoted 9 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
#3 lore raw
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 5 lines
Quoted 2 lines

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 ?

Signature · 1 line
                                                 Gilles.
author
#4 lore raw
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 7 lines
Quoted 4 lines
Quoted 2 lines

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

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
#5 lore raw
Quoted 16 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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 ?

Quoted 8 lines

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 ?

Signature · 1 line
                                                 Gilles.
author
#6 lore raw
Quoted 21 lines · Gilles Chanteperdrix
Quoted 20 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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?

Quoted 8 lines
Quoted 3 lines

[ 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

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
#7 lore raw
Quoted 25 lines · Jan Kiszka
Quoted 24 lines · Gilles Chanteperdrix
Quoted 23 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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. ]

Quoted 7 lines
Quoted 4 lines

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.

Quoted 1 line

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

Signature · 1 line
                                                 Gilles.
author
#8 lore raw
Quoted 37 lines · Gilles Chanteperdrix
Quoted 25 lines · Jan Kiszka
Quoted 24 lines · Gilles Chanteperdrix
Quoted 23 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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. ]

Quoted 6 lines
Quoted 4 lines

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.

Quoted 5 lines
Quoted 1 line

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

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
#9 lore raw
Quoted 38 lines · Jan Kiszka
Quoted 37 lines · Gilles Chanteperdrix
Quoted 25 lines · Jan Kiszka
Quoted 24 lines · Gilles Chanteperdrix
Quoted 23 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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. ]

Quoted 6 lines
Quoted 4 lines

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.

Quoted 1 line

Jan - who seems to have run into alignment issues of cmpxchg on x86_64

Quoted 8 lines
Quoted 3 lines

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.

Signature · 1 line
                                                 Gilles.
author
#10 lore raw
Quoted 47 lines · Gilles Chanteperdrix
Quoted 37 lines · Jan Kiszka
Quoted 36 lines · Gilles Chanteperdrix
Quoted 25 lines · Jan Kiszka
Quoted 24 lines · Gilles Chanteperdrix
Quoted 23 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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. ]

Quoted 6 lines
Quoted 4 lines

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.

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 5 lines

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(-)
ksrc/skins/posix/mutex.c +5 -5
Index: 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));
#11 lore raw
Quoted 47 lines · Jan Kiszka
Quoted 46 lines · Gilles Chanteperdrix
Quoted 45 lines · Jan Kiszka
Quoted 32 lines · Gilles Chanteperdrix
Quoted 25 lines · Jan Kiszka
Quoted 24 lines · Gilles Chanteperdrix
Quoted 23 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 7 lines · Jan Kiszka
Quoted 6 lines · Gilles Chanteperdrix
Quoted 5 lines · Jan Kiszka

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.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

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. ]

Quoted 6 lines
Quoted 4 lines

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.

Quoted 8 lines

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.

Quoted 1 line

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

Quoted 8 lines
Quoted 5 lines

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.

Signature · 1 line
                                                 Gilles.