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 options into the
> kernel "namespace" options. But it seems that CONFIG_SMP is directly set
> by 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...


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to