PREEMPT_RT support

PREEMPT_RT support

[Darren Hart]

I'm looking at how to best support PREEMPT_RT. We have a few things in 
the works which prevent the ideal scenario (which is just a new recipe 
using the preempt_rt branch in linux-yocto).

2.6.34 never had an -rt patch. The WR folks created one that builds and 
is undergoing review from tglx - but that doesn't appear to be near the 
top of his stack. 2.6.37 is still pending an -rt patch, also blocked on 
-tglx.

I'm thinking of creating a meta-rt layer which would provide a latest 
-rt kernel and the rt-tests suite along with a non-graphical image 
definition that facilitates latency detection and rt performance 
measurement. poky-image-rt-test or something along those lines.

Any objection to this approach? As we will eventually move these recipes 
into the core poky recipes, I'd suggest we put this in an 
"experimental/meta_rt" git repository.

Thoughts?

-- 
Darren Hart
Yocto Linux Kernel

Re: PREEMPT_RT support

[Bruce Ashfield]

On 10-12-06 6:06 PM, Darren Hart wrote:
> I'm looking at how to best support PREEMPT_RT. We have a few things in
> the works which prevent the ideal scenario (which is just a new recipe
> using the preempt_rt branch in linux-yocto).
>
> 2.6.34 never had an -rt patch. The WR folks created one that builds and
> is undergoing review from tglx - but that doesn't appear to be near the
> top of his stack. 2.6.37 is still pending an -rt patch, also blocked on
> -tglx.

We'll be doing one at WR eventually, so it will exist in
one form or another for version > 2.6.34.

>
> I'm thinking of creating a meta-rt layer which would provide a latest
> -rt kernel and the rt-tests suite along with a non-graphical image
> definition that facilitates latency detection and rt performance
> measurement. poky-image-rt-test or something along those lines.
>
> Any objection to this approach? As we will eventually move these recipes
> into the core poky recipes, I'd suggest we put this in an
> "experimental/meta_rt" git repository.

I'm worrying about this muddying the water with respect to the
-rt branches in the linux-yocto repositories. In particular if
we go *backward* from the 2.6.34 variant that we already have
(remember, that -rt kernel has been heavily abused for 9
months now and is just as stable (probably more so for
non-x86) as anything else you'll find).

Why can't we continue to consolidate these into fewer kernels
and recipes ? We can't share fixes and BSPs easily if everything
is kept separate. We can obviously pair the tests/utilities along
with the linux-yocto -rt branches, so I'd prefer that approach
and continue to work on improving the base that we already
have.

Cheers,

Bruce

>
> Thoughts?
>

Re: PREEMPT_RT support

[Bruce Ashfield]

On 10-12-06 8:00 PM, Bruce Ashfield wrote:
> On 10-12-06 6:06 PM, Darren Hart wrote:
>> I'm looking at how to best support PREEMPT_RT. We have a few things in
>> the works which prevent the ideal scenario (which is just a new recipe
>> using the preempt_rt branch in linux-yocto).
>>
>> 2.6.34 never had an -rt patch. The WR folks created one that builds and
>> is undergoing review from tglx - but that doesn't appear to be near the
>> top of his stack. 2.6.37 is still pending an -rt patch, also blocked on
>> -tglx.
>
> We'll be doing one at WR eventually, so it will exist in
> one form or another for version>  2.6.34.
>
>>
>> I'm thinking of creating a meta-rt layer which would provide a latest
>> -rt kernel and the rt-tests suite along with a non-graphical image
>> definition that facilitates latency detection and rt performance
>> measurement. poky-image-rt-test or something along those lines.
>>
>> Any objection to this approach? As we will eventually move these recipes
>> into the core poky recipes, I'd suggest we put this in an
>> "experimental/meta_rt" git repository.
>
> I'm worrying about this muddying the water with respect to the
> -rt branches in the linux-yocto repositories. In particular if
> we go *backward* from the 2.6.34 variant that we already have
> (remember, that -rt kernel has been heavily abused for 9
> months now and is just as stable (probably more so for
> non-x86) as anything else you'll find).
>
> Why can't we continue to consolidate these into fewer kernels
> and recipes ? We can't share fixes and BSPs easily if everything
> is kept separate. We can obviously pair the tests/utilities along
> with the linux-yocto -rt branches, so I'd prefer that approach
> and continue to work on improving the base that we already
> have.

I re-read this and my message really isn't clear. I like the
approach. As we agreed before, that we need a separate recipe
that highlights the -rt and builds from a known base. The tests
and surrounding infrastructure are great, and we can have
multiple sources for -rt goodness. I'm just suggesting that
we use the 2.6.34 variant at least on a level playing field
with the 2.6.33-rt, since our 2.6.34 can support all the official
BSPs and features that have merged into the 0.9 kernel.

Cheers,

Bruce

>
> Cheers,
>
> Bruce
>
>>
>> Thoughts?
>>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

Re: PREEMPT_RT support

[Darren Hart]

On 12/06/2010 05:00 PM, Bruce Ashfield wrote:
> On 10-12-06 6:06 PM, Darren Hart wrote:
>> I'm looking at how to best support PREEMPT_RT. We have a few things in
>> the works which prevent the ideal scenario (which is just a new recipe
>> using the preempt_rt branch in linux-yocto).
>>
>> 2.6.34 never had an -rt patch. The WR folks created one that builds and
>> is undergoing review from tglx - but that doesn't appear to be near the
>> top of his stack. 2.6.37 is still pending an -rt patch, also blocked on
>> -tglx.
>
> We'll be doing one at WR eventually, so it will exist in
> one form or another for version > 2.6.34.

My wording above wasn't quite right. tglx will be releasing a 2.6.37 -rt 
tree, that is committed. We're just waiting for it to emerge. There are 
a handful of reworks that will begin with 2.6.37 and may delay things 
some, but it will emerge.

>
>>
>> I'm thinking of creating a meta-rt layer which would provide a latest
>> -rt kernel and the rt-tests suite along with a non-graphical image
>> definition that facilitates latency detection and rt performance
>> measurement. poky-image-rt-test or something along those lines.
>>
>> Any objection to this approach? As we will eventually move these recipes
>> into the core poky recipes, I'd suggest we put this in an
>> "experimental/meta_rt" git repository.
>
> I'm worrying about this muddying the water with respect to the
> -rt branches in the linux-yocto repositories. In particular if
> we go *backward* from the 2.6.34 variant that we already have
> (remember, that -rt kernel has been heavily abused for 9
> months now and is just as stable (probably more so for
> non-x86) as anything else you'll find).
>
> Why can't we continue to consolidate these into fewer kernels
> and recipes ? We can't share fixes and BSPs easily if everything
> is kept separate. We can obviously pair the tests/utilities along
> with the linux-yocto -rt branches, so I'd prefer that approach
> and continue to work on improving the base that we already
> have.

Hrm. Perhaps my perception of the 2.6.34 kernel is flawed. I wasn't 
aware that this particular version of the patch had seen so much 
runtime. If that is the case, instead of an rt-layer, I'll just prepare 
an rt kernel recipe (as we discussed) using the linux-yocto kernel and 
add rt-tests. Both to the core poky meta dir.

I think it would still make sense to have a linux-rt_tip.bb, which 
builds from linux-2.6-tip.git/rt/head as a sort of developers kernel. 
Perhaps this would work well with the other dev recipes you have simmering?


-- 
Darren Hart
Yocto Linux Kernel

Re: PREEMPT_RT support

[Bruce Ashfield]

On Mon, Dec 6, 2010 at 10:35 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 12/06/2010 05:00 PM, Bruce Ashfield wrote:
>>
>> On 10-12-06 6:06 PM, Darren Hart wrote:
>>>
>>> I'm looking at how to best support PREEMPT_RT. We have a few things in
>>> the works which prevent the ideal scenario (which is just a new recipe
>>> using the preempt_rt branch in linux-yocto).
>>>
>>> 2.6.34 never had an -rt patch. The WR folks created one that builds and
>>> is undergoing review from tglx - but that doesn't appear to be near the
>>> top of his stack. 2.6.37 is still pending an -rt patch, also blocked on
>>> -tglx.
>>
>> We'll be doing one at WR eventually, so it will exist in
>> one form or another for version > 2.6.34.
>
> My wording above wasn't quite right. tglx will be releasing a 2.6.37 -rt
> tree, that is committed. We're just waiting for it to emerge. There are a
> handful of reworks that will begin with 2.6.37 and may delay things some,
> but it will emerge.

Right, I recall hearing that at the plumbers conference as well.
I'd like to 'abstract' my statement such that, we can always consider
doing ports if for some reason the upstream tree doesn't move
or match the cadence. We've had to do a 2.6.27 and .34 custom -rt
inside Wind River for just this reason.

>
>>
>>>
>>> I'm thinking of creating a meta-rt layer which would provide a latest
>>> -rt kernel and the rt-tests suite along with a non-graphical image
>>> definition that facilitates latency detection and rt performance
>>> measurement. poky-image-rt-test or something along those lines.
>>>
>>> Any objection to this approach? As we will eventually move these recipes
>>> into the core poky recipes, I'd suggest we put this in an
>>> "experimental/meta_rt" git repository.
>>
>> I'm worrying about this muddying the water with respect to the
>> -rt branches in the linux-yocto repositories. In particular if
>> we go *backward* from the 2.6.34 variant that we already have
>> (remember, that -rt kernel has been heavily abused for 9
>> months now and is just as stable (probably more so for
>> non-x86) as anything else you'll find).
>>
>> Why can't we continue to consolidate these into fewer kernels
>> and recipes ? We can't share fixes and BSPs easily if everything
>> is kept separate. We can obviously pair the tests/utilities along
>> with the linux-yocto -rt branches, so I'd prefer that approach
>> and continue to work on improving the base that we already
>> have.
>
> Hrm. Perhaps my perception of the 2.6.34 kernel is flawed. I wasn't aware
> that this particular version of the patch had seen so much runtime. If that

It has been used a lot, even deployed in products, the stabilization
was long running on about 15 or 20 targets. I'm confident that it has
seen enough burn time

> is the case, instead of an rt-layer, I'll just prepare an rt kernel recipe
> (as we discussed) using the linux-yocto kernel and add rt-tests. Both to the
> core poky meta dir.

This works, and we can update the -rt branches in the 2.6.34 based
kernel to suit.

Cheers,

Bruce

>
> I think it would still make sense to have a linux-rt_tip.bb, which builds
> from linux-2.6-tip.git/rt/head as a sort of developers kernel. Perhaps this
> would work well with the other dev recipes you have simmering?
>
>
> --
> Darren Hart
> Yocto Linux Kernel
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

PREEMPT_RT support

[Jean-Michel Hautbois]

Hi all !

I wanted to try PREEMPT_RT. I added the support for it:
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index c7880f375518..b0360167574d 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -39,6 +39,7 @@ config M68K
         select OLD_SIGSUSPEND3
         select UACCESS_MEMCPY if !MMU
         select ZONE_DMA
+       select ARCH_SUPPORTS_RT

  config CPU_BIG_ENDIAN
         def_bool y

And set PREEMPT_RT then it fails to boot:
[    6.517000] BUG: scheduling while atomic: init/1/0x00010001
[    6.518000] Modules linked in:
[    6.519000] CPU: 0 PID: 1 Comm: init Not tainted 
6.10.0-g82c151ee715b-dirty #161
[    6.519000] Stack from 4186dc60:
[    6.519000]         4186dc60 414ad356 414ad356 00000001 418a0010 
418a0010 413a1e6a 414ad356
[    6.519000]         41025098 41483229 414831fb 418a0306 00000001 
00010001 4186dcc4 413a2ef8
[    6.519000]         418a0010 4186dd1c 418a0010 4186c000 413a500a 
4186c000 413a2ea6 413a6934
[    6.519000]         4102c98e 4186dcd8 413a3616 00000002 4186c000 
415e9180 4186dd5c 413a7312
[    6.519000]         00002700 00000000 00000001 413a500a d0af2266 
41f31552 4186c000 415e9180
[    6.519000]         4102e7b4 415e9180 418a0011 00000001 415e9180 
413a67c6 00000000 4186dd1c
[    6.519000] Call Trace: [<413a1e6a>] dump_stack+0xc/0x10
[    6.519000]  [<41025098>] __schedule_bug+0x50/0x64
[    6.519000]  [<413a2ef8>] __schedule+0x52/0x4ce
[    6.519000]  [<413a500a>] mutex_unlock+0x0/0x6
[    6.519000]  [<413a2ea6>] __schedule+0x0/0x4ce
[    6.519000]  [<413a6934>] try_to_take_rt_mutex+0x0/0x1ee
[    6.519000]  [<4102c98e>] __wake_up_common_lock+0x36/0x46
[    6.519000]  [<413a3616>] schedule_rtlock+0x26/0x46
[    6.519000]  [<413a7312>] rtlock_slowlock_locked+0x5f2/0x8e2
[    6.519000]  [<413a500a>] mutex_unlock+0x0/0x6
[    6.519000]  [<4102e7b4>] arch_local_irq_disable+0x0/0xc
[    6.519000]  [<413a67c6>] rt_spin_unlock+0x1c/0x48
[    6.519000]  [<412207ae>] uart_port_dtr_rts+0x18/0x26
[    6.519000]  [<41208ffc>] tty_driver_kref_put+0x0/0x10
[    6.519000]  [<412103f6>] tty_port_raise_dtr_rts+0x18/0x1c
[    6.519000]  [<413a76ec>] rt_spin_lock+0x42/0x7a
[    6.519000]  [<4122059c>] uart_insert_char+0x0/0x78
[    6.519000]  [<410340dc>] __irq_wake_thread+0x0/0x44
[    6.519000]  [<41223e10>] mcf_interrupt+0x28/0x266
[    6.519000]  [<413a500a>] mutex_unlock+0x0/0x6
[    6.519000]  [<410340dc>] __irq_wake_thread+0x0/0x44
[    6.519000]  [<41034156>] __handle_irq_event_percpu+0x36/0xc6
[    6.519000]  [<41220b76>] uart_port_deref+0x0/0x34
[    6.519000]  [<41036be4>] irqd_irq_disabled.isra.0+0x0/0xc
[    6.519000]  [<410341f6>] handle_irq_event_percpu+0x10/0x40
[    6.519000]  [<4103426e>] handle_irq_event+0x48/0x6e
[    6.519000]  [<41037756>] handle_level_irq+0x9a/0xd2
[    6.519000]  [<41220b76>] uart_port_deref+0x0/0x34
[    6.519000]  [<413a67aa>] rt_spin_unlock+0x0/0x48
[    6.519000]  [<41033b7e>] handle_irq_desc+0x1e/0x28
[    6.519000]  [<410036e2>] do_IRQ+0x22/0x34
[    6.519000]  [<410060ce>] inthandler+0x36/0x40
[    6.519000]  [<413a500a>] mutex_unlock+0x0/0x6
[    6.519000]  [<413a67aa>] rt_spin_unlock+0x0/0x48
[    6.519000]  [<4122140e>] uart_write+0x98/0xae
[    6.519000]  [<4120d1ae>] n_tty_write+0x232/0x362
[    6.519000]  [<4119bef6>] iov_iter_revert+0x0/0xb6
[    6.519000]  [<4102cbf0>] woken_wake_function+0x0/0x2e
[    6.519000]  [<412093c0>] signal_pending+0x0/0x22
[    6.519000]  [<4120a4ec>] file_tty_write.constprop.0+0x156/0x1c0
[    6.519000]  [<410aff7e>] vfs_write+0x104/0x164
[    6.519000]  [<410b00f6>] ksys_write+0x62/0x9e
[    6.519000]  [<410b0132>] sys_write+0x0/0x18
[    6.519000]  [<410b0144>] sys_write+0x12/0x18
[    6.519000]  [<41005fa4>] system_call+0x54/0xa8
[    6.519000]
[    6.520000] ------------[ cut here ]------------
[    6.520000] WARNING: CPU: 0 PID: 0 at kernel/context_tracking.c:128 
ct_kernel_exit.constprop.0+0x34/0x74
[    6.520000] Modules linked in:
[    6.520000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W 
6.10.0-g82c151ee715b-dirty #161
[    6.520000] Stack from 41509ef8:
[    6.520000]         41509ef8 414ad356 414ad356 00000000 00000009 
413997d2 413a1e6a 414ad356
[    6.520000]         4139919c 4147f834 413a2700 41487ce2 41582928 
41028f28 41009894 41487ce2
[    6.520000]         00000080 413a2604 00000009 00000000 00000000 
413a2776 00000000 4101f954
[    6.520000]         00000001 00000002 41508000 418a0010 41508000 
413a27b0 413a2604 41487ce2
[    6.520000]         00000080 00000009 00000000 413a27c8 4102ad8a 
00000002 4102ad24 4101e6f6
[    6.520000]         4103b6ca 41509ff8 4102afda 4103f09c 413a287c 
000000ec 415b524a 418740b0
[    6.520000] Call Trace: [<413997d2>] _printk+0x0/0x18
[    6.520000]  [<413a1e6a>] dump_stack+0xc/0x10
[    6.520000]  [<4139919c>] __warn+0x74/0xc2
[    6.520000]  [<413a2700>] ct_nmi_enter+0x14/0x7e
[    6.520000]  [<41028f28>] arch_local_irq_disable+0x0/0xc
[    6.520000]  [<41009894>] warn_slowpath_fmt+0x6e/0xc6
[    6.520000]  [<413a2604>] ct_kernel_exit.constprop.0+0x34/0x74
[    6.520000]  [<413a2776>] cpu_idle_poll.isra.0+0x0/0x3a
[    6.520000]  [<4101f954>] parse_args+0x0/0x31a
[    6.520000]  [<413a27b0>] default_idle_call+0x0/0x2a
[    6.520000]  [<413a2604>] ct_kernel_exit.constprop.0+0x34/0x74
[    6.520000]  [<413a27c8>] default_idle_call+0x18/0x2a
[    6.520000]  [<4102ad8a>] do_idle+0x66/0x9e
[    6.520000]  [<4102ad24>] do_idle+0x0/0x9e
[    6.520000]  [<4101e6f6>] find_task_by_pid_ns+0x0/0x1e
[    6.520000]  [<4103b6ca>] __rcu_read_lock+0x0/0xc
[    6.520000]  [<4102afda>] cpu_startup_entry+0x14/0x16
[    6.520000]  [<4103f09c>] __rcu_read_unlock+0x0/0x106
[    6.520000]  [<413a287c>] kernel_init+0x0/0xf6
[    6.520000]  [<41392654>] strlen+0x0/0x14
[    6.520000]  [<41398ba0>] arch_local_irq_disable+0x0/0xc
[    6.520000]  [<415a29c8>] console_on_rootfs+0x0/0x58
[    6.520000]  [<41003100>] _exit+0x0/0x4

Any idea, thoughts :-) ?
Thanks a lot !
JM

Re: PREEMPT_RT support

[John Paul Adrian Glaubitz]

Hello Jean-Michel,

On Mon, 2024-09-30 at 10:19 +0200, Jean-Michel Hautbois wrote:
> I wanted to try PREEMPT_RT. I added the support for it:
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index c7880f375518..b0360167574d 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -39,6 +39,7 @@ config M68K
>          select OLD_SIGSUSPEND3
>          select UACCESS_MEMCPY if !MMU
>          select ZONE_DMA
> +       select ARCH_SUPPORTS_RT
> 
>   config CPU_BIG_ENDIAN
>          def_bool y
> 
> And set PREEMPT_RT then it fails to boot:
> [    6.517000] BUG: scheduling while atomic: init/1/0x00010001
> (...)
> Any idea, thoughts :-) ?

From what I know an architecture has to be explicitly ported to support
a realtime kernel. Simply enabling the feature therefore won't work.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: PREEMPT_RT support

[Michael Schmitz]

Hi Adrian,

Am 30.09.2024 um 21:38 schrieb John Paul Adrian Glaubitz:
> Hello Jean-Michel,
>
> On Mon, 2024-09-30 at 10:19 +0200, Jean-Michel Hautbois wrote:
>> I wanted to try PREEMPT_RT. I added the support for it:
>> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
>> index c7880f375518..b0360167574d 100644
>> --- a/arch/m68k/Kconfig
>> +++ b/arch/m68k/Kconfig
>> @@ -39,6 +39,7 @@ config M68K
>>          select OLD_SIGSUSPEND3
>>          select UACCESS_MEMCPY if !MMU
>>          select ZONE_DMA
>> +       select ARCH_SUPPORTS_RT
>>
>>   config CPU_BIG_ENDIAN
>>          def_bool y
>>
>> And set PREEMPT_RT then it fails to boot:
>> [    6.517000] BUG: scheduling while atomic: init/1/0x00010001
>> (...)
>> Any idea, thoughts :-) ?
>
> From what I know an architecture has to be explicitly ported to support
> a realtime kernel. Simply enabling the feature therefore won't work.

Making sure softirqs are run from a separate kernel thread and not from 
atomic context would be a good start. Adding preempt_disable() / 
preempt_enable() around more critcal sections may be needed as well.

Git history of those architectures that support PREEMPT_RT might be 
informative.

Cheers,

	Michael


>
> Adrian
>