[Xenomai-help] Xenomai configure --enable-smp vs. SMP kernel configuration

[Xenomai-help] Xenomai configure --enable-smp vs. SMP kernel configuration

[M. Koehrer]

Hi everybody,

I want to know why the --enable-smp option for "configure" of Xenomai is used when there
is already the corresponding option selected with the kernel configuration?
In other words:
Isn't it possible to get the value from the kernel configuration to configure Xenomai itself properly?
Or: What effects could result from a wrongly configured Xenomai (e.g. kernel with SMP,
Xenomai configured without --enable-smp)?

Thanks for any answers on that questions.

Regards

Mathias


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai configure --enable-smp vs. SMP kernel configuration

[Philippe Gerum]

On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
> Hi everybody,
> 
> I want to know why the --enable-smp option for "configure" of Xenomai is used when there
> is already the corresponding option selected with the kernel configuration?

--enable-smp is only used when you want the user-space side to _require_
SMP support to be present into the running kernel; i.e. for some (weird)
reason, your application really needs this. Xenomai libraries don't care
whether SMP support is enabled or not, they are not sensitive to that
issue (see the "weak" status of this option in README.INSTALL)

I agree that this could be a bit confusing, I guess that the
documentation needs an update to clarify this point.

> In other words:
> Isn't it possible to get the value from the kernel configuration to configure Xenomai itself properly?

No, we cannot anymore since v2.1, at least not at build time. The point
is that we have totally decoupled the build processes between kernel and
user-space supports. Having no build-time dependencies from the
user-space libs on the internal structures we use in kernel space is
what allows you to run older application binaries on newer Xenomai
releases, unless we had to change the syscall ABI for some very good
reason (which is seldom).

The point is that we try hard to be friendly to people deploying Xenomai
installs in the field, so that they don't have to always rebuild the
whole stuff would they want to only upgrade part of their setup. There
is a built-in ABI revision value dynamically shared between the kernel
and user-space code at application startup to trap potential mismatches.

> Or: What effects could result from a wrongly configured Xenomai (e.g. kernel with SMP,
> Xenomai configured without --enable-smp)?

None, it would work, provided your application code does not depend on
the SMP feature in some tricky ways it would be the only one to know
about (again, Xenomai libs just don't care, there are no build-time
dependencies on the kernel support here).

> 
> Thanks for any answers on that questions.
> 
> Regards
> 
> Mathias
> 
> 
-- 
Philippe.

[Xenomai-core] CONFIG_SMP in switchtest (was: Xenomai configure --enable-smp...)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

Philippe Gerum wrote:
> On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
>> Hi everybody,
>>
>> I want to know why the --enable-smp option for "configure" of Xenomai is used when there
>> is already the corresponding option selected with the kernel configuration?
> 
> --enable-smp is only used when you want the user-space side to _require_
> SMP support to be present into the running kernel; i.e. for some (weird)
> reason, your application really needs this. Xenomai libraries don't care
> whether SMP support is enabled or not, they are not sensitive to that
> issue (see the "weak" status of this option in README.INSTALL)

Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
OK, but I wonder if this is required. Gilles?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] CONFIG_SMP in switchtest

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
>>
>>>Hi everybody,
>>>
>>>I want to know why the --enable-smp option for "configure" of Xenomai is used when there
>>>is already the corresponding option selected with the kernel configuration?
>>
>>--enable-smp is only used when you want the user-space side to _require_
>>SMP support to be present into the running kernel; i.e. for some (weird)
>>reason, your application really needs this. Xenomai libraries don't care
>>whether SMP support is enabled or not, they are not sensitive to that
>>issue (see the "weak" status of this option in README.INSTALL)
> 
> 
> Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
> OK, but I wonder if this is required. Gilles?

If you do not enable the smp option, switchtest will only use one cpu.
The reason why I made this is that, on some UP machine, (probably arm,
but I do no longer remember) sysconf(_SC_NPROCESSORS_ONLN) did not work.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] CONFIG_SMP in switchtest

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
>>>
>>>> Hi everybody,
>>>>
>>>> I want to know why the --enable-smp option for "configure" of Xenomai is used when there
>>>> is already the corresponding option selected with the kernel configuration?
>>> --enable-smp is only used when you want the user-space side to _require_
>>> SMP support to be present into the running kernel; i.e. for some (weird)
>>> reason, your application really needs this. Xenomai libraries don't care
>>> whether SMP support is enabled or not, they are not sensitive to that
>>> issue (see the "weak" status of this option in README.INSTALL)
>>
>> Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
>> OK, but I wonder if this is required. Gilles?
> 
> If you do not enable the smp option, switchtest will only use one cpu.
> The reason why I made this is that, on some UP machine, (probably arm,
> but I do no longer remember) sysconf(_SC_NPROCESSORS_ONLN) did not work.

Welcome to embedded hell :-/. What was the effect precisely? Can we
detect this during runtime? The point is I see people trying this test
on SMP without providing the right switch to configure. Would be a pity
IMHO.

At this chance: I also noticed problems with our sched_setscheduler
detection and bfin's uClibc. Compilations works, linking fails - they
provide headers, but lack implementations. Patch suggestion will follow.

And my pthread_spin_lock detection got nicely vaporised on bfin once
again. I'm considering to switch back to the original configure-based
detection.

Enough of the moaning.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] CONFIG_SMP in switchtest

[Philippe Gerum]

On Tue, 2007-06-12 at 19:59 +0200, Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>
> >>> On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
> >>>
> >>>> Hi everybody,
> >>>>
> >>>> I want to know why the --enable-smp option for "configure" of Xenomai is used when there
> >>>> is already the corresponding option selected with the kernel configuration?
> >>> --enable-smp is only used when you want the user-space side to _require_
> >>> SMP support to be present into the running kernel; i.e. for some (weird)
> >>> reason, your application really needs this. Xenomai libraries don't care
> >>> whether SMP support is enabled or not, they are not sensitive to that
> >>> issue (see the "weak" status of this option in README.INSTALL)
> >>
> >> Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
> >> OK, but I wonder if this is required. Gilles?
> > 
> > If you do not enable the smp option, switchtest will only use one cpu.
> > The reason why I made this is that, on some UP machine, (probably arm,
> > but I do no longer remember) sysconf(_SC_NPROCESSORS_ONLN) did not work.
> 
> Welcome to embedded hell :-/. What was the effect precisely? Can we
> detect this during runtime? The point is I see people trying this test
> on SMP without providing the right switch to configure. Would be a pity
> IMHO.
> 
> At this chance: I also noticed problems with our sched_setscheduler
> detection and bfin's uClibc. Compilations works, linking fails - they
> provide headers, but lack implementations. Patch suggestion will follow.
> 
> And my pthread_spin_lock detection got nicely vaporised on bfin once
> again. I'm considering to switch back to the original configure-based
> detection.

Notice that you have no atomic ops available on Blackfin CPUs, and to
emulate them, you would have to mask interrupts, which you can't do in
user-space (privileged instruction). So you will always end up issuing a
syscall under the hood (bfin_spinlock), that does some kind of spinlock
emulation from kernel space. Next kernel releases might improve things
by allowing to jump to atomic emulation routines directly from
user-space, but this is not yet available AFAIK. IOW, don't expect
performance improvements from user-space locking, yet.

> 
> Enough of the moaning.
> 

Still, this is quite a fun architecture to work with.

> Jan
> 
-- 
Philippe.

Re: [Xenomai-core] CONFIG_SMP in switchtest

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]

Philippe Gerum wrote:
> On Tue, 2007-06-12 at 19:59 +0200, Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>
>>>>> On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
>>>>>
>>>>>> Hi everybody,
>>>>>>
>>>>>> I want to know why the --enable-smp option for "configure" of Xenomai is used when there
>>>>>> is already the corresponding option selected with the kernel configuration?
>>>>> --enable-smp is only used when you want the user-space side to _require_
>>>>> SMP support to be present into the running kernel; i.e. for some (weird)
>>>>> reason, your application really needs this. Xenomai libraries don't care
>>>>> whether SMP support is enabled or not, they are not sensitive to that
>>>>> issue (see the "weak" status of this option in README.INSTALL)
>>>> Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
>>>> OK, but I wonder if this is required. Gilles?
>>> If you do not enable the smp option, switchtest will only use one cpu.
>>> The reason why I made this is that, on some UP machine, (probably arm,
>>> but I do no longer remember) sysconf(_SC_NPROCESSORS_ONLN) did not work.
>> Welcome to embedded hell :-/. What was the effect precisely? Can we
>> detect this during runtime? The point is I see people trying this test
>> on SMP without providing the right switch to configure. Would be a pity
>> IMHO.
>>
>> At this chance: I also noticed problems with our sched_setscheduler
>> detection and bfin's uClibc. Compilations works, linking fails - they
>> provide headers, but lack implementations. Patch suggestion will follow.
>>
>> And my pthread_spin_lock detection got nicely vaporised on bfin once
>> again. I'm considering to switch back to the original configure-based
>> detection.
> 
> Notice that you have no atomic ops available on Blackfin CPUs, and to
> emulate them, you would have to mask interrupts, which you can't do in
> user-space (privileged instruction). So you will always end up issuing a
> syscall under the hood (bfin_spinlock), that does some kind of spinlock
> emulation from kernel space. Next kernel releases might improve things
> by allowing to jump to atomic emulation routines directly from
> user-space, but this is not yet available AFAIK. IOW, don't expect
> performance improvements from user-space locking, yet.

For now my point was the old uClibc issue "define _POSIX_SPIN_LOCKS, but
avoid to implement it". Blackfin's toolchain managed to do the second
part differently, and no longer detectable without configure's help.

> 
>> Enough of the moaning.
>>
> 
> Still, this is quite a fun architecture to work with.

Yeah, it basically worked here already (with latest release, to answer
your other mail), some Xenomai tests (non-POSIX) used to run. But now
I'm a bit off-road (SVN head) to apply patches and fix quirks I came
across. That's where the fun really starts... :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] CONFIG_SMP in switchtest

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
>>>>
>>>>
>>>>>Hi everybody,
>>>>>
>>>>>I want to know why the --enable-smp option for "configure" of Xenomai is used when there
>>>>>is already the corresponding option selected with the kernel configuration?
>>>>
>>>>--enable-smp is only used when you want the user-space side to _require_
>>>>SMP support to be present into the running kernel; i.e. for some (weird)
>>>>reason, your application really needs this. Xenomai libraries don't care
>>>>whether SMP support is enabled or not, they are not sensitive to that
>>>>issue (see the "weak" status of this option in README.INSTALL)
>>>
>>>Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
>>>OK, but I wonder if this is required. Gilles?
>>
>>If you do not enable the smp option, switchtest will only use one cpu.
>>The reason why I made this is that, on some UP machine, (probably arm,
>>but I do no longer remember) sysconf(_SC_NPROCESSORS_ONLN) did not work.
> 
> 
> Welcome to embedded hell :-/. What was the effect precisely? Can we
> detect this during runtime? The point is I see people trying this test
> on SMP without providing the right switch to configure. Would be a pity
> IMHO.

I find the current behaviour consistent: if you do not enable smp, the
test only uses one CPU. But works.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] CONFIG_SMP in switchtest

[Philippe Gerum]

On Tue, 2007-06-12 at 19:59 +0200, Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>
> >>> On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
> >>>
> >>>> Hi everybody,
> >>>>
> >>>> I want to know why the --enable-smp option for "configure" of Xenomai is used when there
> >>>> is already the corresponding option selected with the kernel configuration?
> >>> --enable-smp is only used when you want the user-space side to _require_
> >>> SMP support to be present into the running kernel; i.e. for some (weird)
> >>> reason, your application really needs this. Xenomai libraries don't care
> >>> whether SMP support is enabled or not, they are not sensitive to that
> >>> issue (see the "weak" status of this option in README.INSTALL)
> >>
> >> Switchtest bases some compile-time decisions on CONFIG_SMP. Nitpicking,
> >> OK, but I wonder if this is required. Gilles?
> > 
> > If you do not enable the smp option, switchtest will only use one cpu.
> > The reason why I made this is that, on some UP machine, (probably arm,
> > but I do no longer remember) sysconf(_SC_NPROCESSORS_ONLN) did not work.
> 
> Welcome to embedded hell :-/. What was the effect precisely? Can we
> detect this during runtime? The point is I see people trying this test
> on SMP without providing the right switch to configure. Would be a pity
> IMHO.
> 
> At this chance: I also noticed problems with our sched_setscheduler
> detection and bfin's uClibc. Compilations works, linking fails - they
> provide headers, but lack implementations. Patch suggestion will follow.
> 

The main point with the Blackfin port is: which uclinux-dist release are
you using? We are currently based on 2007R1-RC3. The uclinux-dist effort
is still largely in flux right now, so this makes a significant
difference.

> And my pthread_spin_lock detection got nicely vaporised on bfin once
> again. I'm considering to switch back to the original configure-based
> detection.
> 
> Enough of the moaning.
> 
> Jan
> 
-- 
Philippe.