Re: [Xenomai-core] [PATCH] userspace: Make CONFIG_SMP default

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.


-- 
                                                 Gilles.