[Xenomai] Some Information About compilation Xenomai and RT Patches

[Xenomai] Some Information About compilation Xenomai and RT Patches

[Jean Rodriguez]

Hi guys,

I’m trying to compile kernel 3.8 with the last xenomai source.

I want to know some precisions about preempt option.

Is it useless to patch the kernel with with Xenomai and also with RT patch
from kernel.org?

Because With RT patch I can choose on menuconfig  Preemption Model 5 choices
(No preempt, Voluntary and low latency , preemptible kernel or fully
preemptivekernel)

But if I patch only with xenomai I have just 3 choices of preemptive (No
preempt, Voluntary and low latency)

If patch first with RT and after xenomai I have a lot of Hunk message
(warning and error) but if  I Patch first with xenomai and after RT -> no
problem



So my question are they compatible together? Or perhaps choosing fully
preemptive will turn my system unstable.



My goal is to catch Interruption with a small latency (50-10 µs) with a low
processor charge

Board  Arbor card
<http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
=1&version=+Default> EmETX-i2900  with ATOM N450





Thanks for your future response





Kind regards,



Jean Rodriguez

Ingénieur R&D Informatique













---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Stoidner, Christoph]

Hi Jean,

I have merged successfully I-Pipe/Xenomai and Preempt RT patch for Kernel V3.10.18. From my point of view it is working very well. The only part which was a bit of tricky to solve was the kernel's spinlock implementation. This is since I-Pipe as well as Preempt-RT are patching this part of code each with own implementations. As result it is required to replace Preempt RT's default spinlock calls with new wrappers. Within the wrappers you have to decide if Preempt RT's spinlock or I-Pipe's spinlock have to be used at this place.

My pending problem which I hope to solve soon is the fast context switch extension (FCSE) that allows better latency times on ARM9. In "guaranteed" mode it crashs when using addresses above 32MB.

If you are interested in more details feel free to ask.

Regards,
Christoph



________________________________________
Von: Xenomai <xenomai-bounces@xenomai.org> im Auftrag von Jean Rodriguez <j.rodriguez@caustier.com>
Gesendet: Dienstag, 17. Juni 2014 17:00
An: xenomai@xenomai.org
Betreff: [Xenomai] Some Information About compilation Xenomai and RT Patches

Hi guys,

I’m trying to compile kernel 3.8 with the last xenomai source.

I want to know some precisions about preempt option.

Is it useless to patch the kernel with with Xenomai and also with RT patch
from kernel.org?

Because With RT patch I can choose on menuconfig  Preemption Model 5 choices
(No preempt, Voluntary and low latency , preemptible kernel or fully
preemptivekernel)

But if I patch only with xenomai I have just 3 choices of preemptive (No
preempt, Voluntary and low latency)

If patch first with RT and after xenomai I have a lot of Hunk message
(warning and error) but if  I Patch first with xenomai and after RT -> no
problem



So my question are they compatible together? Or perhaps choosing fully
preemptive will turn my system unstable.



My goal is to catch Interruption with a small latency (50-10 µs) with a low
processor charge

Board  Arbor card
<http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
=1&version=+Default> EmETX-i2900  with ATOM N450





Thanks for your future response





Kind regards,



Jean Rodriguez

Ingénieur R&D Informatique













---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Philippe Gerum]

On 06/17/2014 05:00 PM, Jean Rodriguez wrote:
> Hi guys,
>
> I’m trying to compile kernel 3.8 with the last xenomai source.
>
> I want to know some precisions about preempt option.
>
> Is it useless to patch the kernel with with Xenomai and also with RT patch
> from kernel.org?

Combining both makes sense only if your use case involves response time 
requirements when running regular linux activities, in addition to the 
real-time duties offloaded to the Xenomai co-kernel. In most cases where 
a dual kernel solution applies, there is no requirement for full 
preemption (-rt) on the regular linux side though.

>
> Because With RT patch I can choose on menuconfig  Preemption Model 5 choices
> (No preempt, Voluntary and low latency , preemptible kernel or fully
> preemptivekernel)
>
> But if I patch only with xenomai I have just 3 choices of preemptive (No
> preempt, Voluntary and low latency)
>

Those choices affect the regular linux kernel behavior only, not 
Xenomai. When the Xenomai co-kernel is present, there is no need for 
additional preemption models, the linux kernel is inherently preemptible 
by Xenomai activities at any time.

> If patch first with RT and after xenomai I have a lot of Hunk message
> (warning and error) but if  I Patch first with xenomai and after RT -> no
> problem
>
>
>
> So my question are they compatible together? Or perhaps choosing fully
> preemptive will turn my system unstable.
>

Combining both is possible, and such configuration is actually used by 
some projects. However, a combo patch merging preempt-rt and the I-pipe 
has to be specifically crafted for the target kernel.

>
>
> My goal is to catch Interruption with a small latency (50-10 µs) with a low
> processor charge

Since there is no one-fits-it-all solution, I would suggest to benchmark 
each configuration separately for your use case, and see which one best 
fits the bill, taking into account the pros and cons of each approach in 
the long run for your project.

>
> Board  Arbor card
> <http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
> =1&version=+Default> EmETX-i2900  with ATOM N450
>
>
>
>
>
> Thanks for your future response
>
>
>
>
>
> Kind regards,
>
>
>
> Jean Rodriguez
>
> Ingénieur R&D Informatique
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---
> Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
> http://www.avast.com
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
Philippe.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Stoidner, Christoph]

Hi Jean,

I have merged successfully I-Pipe/Xenomai and Preempt RT patch for Kernel V3.10.18. From my point of view it is working very well. The only part which was a bit of tricky to solve was the kernel's spinlock implementation. This is since I-Pipe as well as Preempt-RT are patching this part of code each with own implementations. As result it is required to replace Preempt RT's default spinlock calls with new wrappers. Within the wrappers you have to decide if Preempt RT's spinlock or I-Pipe's spinlock have to be used at this place.

My pending problem which I hope to solve soon is the fast context switch extension (FCSE) that allows better latency times on ARM9. In "guaranteed" mode it crashs when using addresses above 32MB.

If you are interested in more details feel free to ask.

Regards,
Christoph



________________________________________
Von: Xenomai <xenomai-bounces@xenomai.org> im Auftrag von Jean Rodriguez <j.rodriguez@caustier.com>
Gesendet: Dienstag, 17. Juni 2014 17:00
An: xenomai@xenomai.org
Betreff: [Xenomai] Some Information About compilation Xenomai and RT Patches

Hi guys,

I’m trying to compile kernel 3.8 with the last xenomai source.

I want to know some precisions about preempt option.

Is it useless to patch the kernel with with Xenomai and also with RT patch
from kernel.org?

Because With RT patch I can choose on menuconfig  Preemption Model 5 choices
(No preempt, Voluntary and low latency , preemptible kernel or fully
preemptivekernel)

But if I patch only with xenomai I have just 3 choices of preemptive (No
preempt, Voluntary and low latency)

If patch first with RT and after xenomai I have a lot of Hunk message
(warning and error) but if  I Patch first with xenomai and after RT -> no
problem



So my question are they compatible together? Or perhaps choosing fully
preemptive will turn my system unstable.



My goal is to catch Interruption with a small latency (50-10 µs) with a low
processor charge

Board  Arbor card
<http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
=1&version=+Default> EmETX-i2900  with ATOM N450





Thanks for your future response





Kind regards,



Jean Rodriguez

Ingénieur R&D Informatique













---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Gilles Chanteperdrix]

On 06/20/2014 11:02 AM, Stoidner, Christoph wrote:
> My pending problem which I hope to solve soon is the fast context
> switch extension (FCSE) that allows better latency times on ARM9. In
> "guaranteed" mode it crashs when using addresses above 32MB.

What do you mean it crashes? Normally, an mmap call that would return
addresses above 32MB simply fails, because you can not use addresses
above 32MB in guaranteed mode.

-- 
                                                                Gilles.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Stoidner, Christoph]

Hi Gilles,

when a userspace application starts it calls the brk() syscall to enlarge it's heap space. In some cases the call leads to an NOMEM error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM error at this place the a segfault exception appears.

It seems as this happens when brk() got an address above some limit, also when the process at all consumes less than 32MB RAM. E.g. busybox shell command "ls" is enough to get the segfault.

Regards,
Christoph


________________________________________
Von: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Gesendet: Freitag, 20. Juni 2014 13:50
An: Stoidner, Christoph; xenomai@xenomai.org
Betreff: Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

On 06/20/2014 11:02 AM, Stoidner, Christoph wrote:
> My pending problem which I hope to solve soon is the fast context
> switch extension (FCSE) that allows better latency times on ARM9. In
> "guaranteed" mode it crashs when using addresses above 32MB.

What do you mean it crashes? Normally, an mmap call that would return
addresses above 32MB simply fails, because you can not use addresses
above 32MB in guaranteed mode.

--
                                                                Gilles.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Gilles Chanteperdrix]

On 06/23/2014 11:33 AM, Stoidner, Christoph wrote:
> 
> Hi Gilles,
> 
> when a userspace application starts it calls the brk() syscall to
> enlarge it's heap space. In some cases the call leads to an NOMEM
> error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM
> error at this place the a segfault exception appears.
> 
> It seems as this happens when brk() got an address above some limit,
> also when the process at all consumes less than 32MB RAM. E.g.
> busybox shell command "ls" is enough to get the segfault.

with the glibc versions I have been testing with the FCSE patch since it
exists, when brk fails, the glibc uses mmap to allocate memory, and
everything continues.

-- 
                                                                Gilles.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Gilles Chanteperdrix]

On 06/23/2014 11:33 AM, Stoidner, Christoph wrote:
> 
> Hi Gilles,
> 
> when a userspace application starts it calls the brk() syscall to
> enlarge it's heap space. In some cases the call leads to an NOMEM
> error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM
> error at this place the a segfault exception appears.
> 
> It seems as this happens when brk() got an address above some limit,
> also when the process at all consumes less than 32MB RAM. E.g.
> busybox shell command "ls" is enough to get the segfault.

Could you test the I-pipe git branch ipipe-3.14, unmodified?

-- 
                                                                Gilles.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Stoidner, Christoph]

Original ipipe-3.10.18 without Preempt-RT works without any problem. The problem occurs only in combination of my Preempt-RT merge and enabled FCSE in guaranteed mode.

Since unmodified ipipe-3.10 does not show the problem I assume unmodified ipipe-3.14 also does not show the problem. Or do you think 3.14 brings some more details?

Regards,
Christoph

________________________________________
Von: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Gesendet: Montag, 23. Juni 2014 11:53
An: Stoidner, Christoph; xenomai@xenomai.org
Betreff: Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

On 06/23/2014 11:33 AM, Stoidner, Christoph wrote:
>
> Hi Gilles,
>
> when a userspace application starts it calls the brk() syscall to
> enlarge it's heap space. In some cases the call leads to an NOMEM
> error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM
> error at this place the a segfault exception appears.
>
> It seems as this happens when brk() got an address above some limit,
> also when the process at all consumes less than 32MB RAM. E.g.
> busybox shell command "ls" is enough to get the segfault.

Could you test the I-pipe git branch ipipe-3.14, unmodified?

--
                                                                Gilles.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Gilles Chanteperdrix]

On 06/23/2014 12:04 PM, Stoidner, Christoph wrote:
> 
> Original ipipe-3.10.18 without Preempt-RT works without any problem.
> The problem occurs only in combination of my Preempt-RT merge and
> enabled FCSE in guaranteed mode.
> 
> Since unmodified ipipe-3.10 does not show the problem I assume
> unmodified ipipe-3.14 also does not show the problem. Or do you think
> 3.14 brings some more details?

I definitely fixed some FCSE issues in the ipipe-3.14 branch, mostly
when FCSE is enabled without CONFIG_IPIPE. Now if ipipe-3.10.18 has no
issues, whereas mixing Prempt-rt in makes some issues appear, I would
suggest looking carefully at the changes introduced by the preempt-rt
patch with regard to mm handling.

-- 
                                                                Gilles.

Re: [Xenomai] Some Information About compilation Xenomai and RT Patches

[Gilles Chanteperdrix]

On 06/24/2014 01:41 AM, Gilles Chanteperdrix wrote:
> On 06/23/2014 12:04 PM, Stoidner, Christoph wrote:
>>
>> Original ipipe-3.10.18 without Preempt-RT works without any problem.
>> The problem occurs only in combination of my Preempt-RT merge and
>> enabled FCSE in guaranteed mode.
>>
>> Since unmodified ipipe-3.10 does not show the problem I assume
>> unmodified ipipe-3.14 also does not show the problem. Or do you think
>> 3.14 brings some more details?
> 
> I definitely fixed some FCSE issues in the ipipe-3.14 branch, mostly
> when FCSE is enabled without CONFIG_IPIPE. Now if ipipe-3.10.18 has no
> issues, whereas mixing Prempt-rt in makes some issues appear, I would
> suggest looking carefully at the changes introduced by the preempt-rt
> patch with regard to mm handling.
> 
Something else, if what you had trouble with is the spinlock merge, you
should maybe double check that ipipe_spinlocks work as expected, because
the FCSE code uses an ipipe_spinlock, and if this spinlock ends up as a
sleeping spinlock, things could get messy.

-- 
                                                                Gilles.