CONFIG PREEMPT RT Patch

From RTwiki
(Difference between revisions)
Jump to: navigation, search
m (Platforms Tested and in Use with CONFIG_PREEMPT_RT)
m (Download)
 
(43 intermediate revisions by 18 users not shown)
Line 2: Line 2:
  
 
The [http://www.kernel.org/pub/linux/kernel/projects/rt/ CONFIG_PREEMPT_RT patch set] is maintained by a small group of core developers, led by Ingo Molnar.  This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions").  This is done by replacing most kernel spinlocks with mutexes that support [[priority inheritance]], as well as moving all interrupt and software interrupts to kernel threads.
 
The [http://www.kernel.org/pub/linux/kernel/projects/rt/ CONFIG_PREEMPT_RT patch set] is maintained by a small group of core developers, led by Ingo Molnar.  This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions").  This is done by replacing most kernel spinlocks with mutexes that support [[priority inheritance]], as well as moving all interrupt and software interrupts to kernel threads.
 
It further incorporates [[high resolution timers]] - a patch set, which is independently maintained.
 
  
 
You can find now a detailed [[RT_PREEMPT_HOWTO]] on this page.
 
You can find now a detailed [[RT_PREEMPT_HOWTO]] on this page.
  
 
Paul McKenney has written a good [http://lwn.net/Articles/146861/ CONFIG_PREEMPT_RT overview] which is a good introduction to the changes introduced to the kernel by the CONFIG_PREEMPT_RT patch.
 
Paul McKenney has written a good [http://lwn.net/Articles/146861/ CONFIG_PREEMPT_RT overview] which is a good introduction to the changes introduced to the kernel by the CONFIG_PREEMPT_RT patch.
 +
 +
An overview about the various components of the CONFIG_PREEMPT_RT patch and their merge status into the mainline kernel is available [http://osadl.org/RT here].
  
 
== Download ==
 
== Download ==
 
The patch set is available [http://www.kernel.org/pub/linux/kernel/projects/rt/ here], as either a single monolithic patch, or in a broken-out tarball.  See [http://www.mail-archive.com/linux-rt-users@vger.kernel.org/msg00592.html the announcement] regarding the broken-out patch set.
 
The patch set is available [http://www.kernel.org/pub/linux/kernel/projects/rt/ here], as either a single monolithic patch, or in a broken-out tarball.  See [http://www.mail-archive.com/linux-rt-users@vger.kernel.org/msg00592.html the announcement] regarding the broken-out patch set.
 +
 +
The CONFIG_PREEMPT_RT patch set is also maintained in a git repo at [http://git.kernel.org/?p=linux/kernel/git/rt/linux-stable-rt.git;a=summary kernel.org].
  
 
There is also an apt repository for Ubuntu with x86 precompiled kernel. You can find more information in this wiki page:
 
There is also an apt repository for Ubuntu with x86 precompiled kernel. You can find more information in this wiki page:
Line 20: Line 22:
 
Please send patches for the CONFIG_PREEMPT_RT Patch Set to LKML and put Ingo Molnar and Thomas Gleixner on CC.
 
Please send patches for the CONFIG_PREEMPT_RT Patch Set to LKML and put Ingo Molnar and Thomas Gleixner on CC.
  
Please do not send clocksource and clockevents related patches against the -rt patch. Make sure they apply against the latest [[High_resolution_timers |-hrt-dyntick patch]]. -hrt-dyntick might be a bit ahead of -rt at times, but the -rt patch pulls -hrt-dyntick on a regular base.
+
Please do not send clocksource and clockevents related patches against the -rt patch. Make sure they apply against
 +
Linus' tree.
  
 
== Platforms Tested and in Use with CONFIG_PREEMPT_RT ==
 
== Platforms Tested and in Use with CONFIG_PREEMPT_RT ==
Line 28: Line 31:
 
! Processor !! Model #'s !! Kernel version(s) !! Contact(s) !! Comment(s)
 
! Processor !! Model #'s !! Kernel version(s) !! Contact(s) !! Comment(s)
 
|-
 
|-
| Opteron || IBM LS-20, LS-21, x3455 ||  2.6.16-rt22, 2.6.20-rt8  || [[User:Tytso | Theodore Ts'o]], [[User:Dvhart | Darren Hart]] ||
+
| Opteron || IBM LS21, LS22, HS21XM, HS22x, 3455, 3550, 3650 ||  2.6.16-rt22, 2.6.20-rt8  || [[User:Tytso | Theodore Ts'o]], [[User:Dvhart | Darren Hart]] || Systems have SMI Remediation support and handle ECC errors via the ibmprtm daemon.
 
|-
 
|-
 
| Xeon    || IBM 6850-P4U            || 2.6.20-rt8, 2.6.21-rc6-rt0|| [[User:Sperryd | Dave Sperry]] ||
 
| Xeon    || IBM 6850-P4U            || 2.6.20-rt8, 2.6.21-rc6-rt0|| [[User:Sperryd | Dave Sperry]] ||
 +
|-
 +
| Intel  Xeon 2.4GHz with HT || HP xw8000  ||  2.6.29.3-rt12          || [[User:rdoursenaud | Raphaël Doursenaud]] ||
 +
|-
 +
| AMD Opteron 175 || ASUS A8N-SLI Premium  ||  2.6.29.3-rt12          || [[User:rdoursenaud | Raphaël Doursenaud]] ||
 
|-
 
|-
 
| P4      || Compaq Evo N610        ||  2.6.16-rt22              || [[User:Sperryd | Dave Sperry]] ||
 
| P4      || Compaq Evo N610        ||  2.6.16-rt22              || [[User:Sperryd | Dave Sperry]] ||
 
|-
 
|-
| P3      || Celeron 1300            ||  2.6.21.5-rt14            || [[User:Post-factum | Oleksandr Natalenko]] ||
+
| P3      || Celeron 1300            ||  2.6.21.5-rt14            || [[User:PostFactum | Oleksandr Natalenko]] ||
 +
|-
 +
| Intel  || Pentium Dual-Core T2330 ||  2.6.29.1-rt4            || [[User:PostFactum | Oleksandr Natalenko]] ||
 
|-
 
|-
 
| Prescott|| PentiumD 3 GHz          ||  2.6.22.6-rt9            || [[User:BlackRaven | Dmitry Pisklov]] ||
 
| Prescott|| PentiumD 3 GHz          ||  2.6.22.6-rt9            || [[User:BlackRaven | Dmitry Pisklov]] ||
 
|-
 
|-
| Intel  || Pentium 4 CPU 2.4 GHz   ||  2.6.23-rc8-rt1           || [[User:Jaswinderlinuxrt | Jaswinder Singh]] ||
+
| Intel  || Pentium 4 2.4 GHz       ||  2.6.23.9-rt12          || [[User:Jaswinderlinuxrt | Jaswinder Singh]] ||
 +
|-
 +
| Intel  || Pentium 4 2.8 GHz with HT  ||  2.6.23.9-rt12           || [[User:Jaswinderlinuxrt | Jaswinder Singh]] ||
 +
|-
 +
| Intel  || [http://www.fujitsu-siemens.com/products/prof_accessories_mainboards/mainboards/industrial/d2151s.html FSC D2151S ] Celeron D 2.93 Ghz      ||  2.6.20-rt8              || [[User:Remy | Remy Bohmer]] || Avg. latency < 10us, worst case latency: < 30us (see Note 1)
 +
|-
 +
| Intel  || [http://www.fujitsu-siemens.com/products/prof_accessories_mainboards/mainboards/industrial/d2151s.html FSC D2151S ] Core 2 Duo E6300        ||  2.6.20-rt8              || [[User:Remy | Remy Bohmer]] || Avg. latency < 10us, worst case latency: < 30us (see Note 1)
 +
|-
 +
| Intel  || [http://www.asus.com/products.aspx?l1=3&l2=11&l3=307&l4=0&model=1179&modelmenu=1 Asus P5B] Core 2 Duo E6600 2.4GHz ||  2.6.23-rc4-rt1          || [[User:Remy | Remy Bohmer]] || Avg. latency < 10us, worst case latency: < 30us (see Note 1)
 +
|-
 +
| Intel  || Core 2 Quad Q6600 || 2.6.24.7-rt27 || [[User:Pauls]] || Works ok, but frequency scaling has to be turned off for decent results. A task run at 1 kHz repetition rate with low load was found to be t-distributed with 4 degrees of freedom, with 1% value 0.9842 ms, 99% value 1.0103 ms (ideal realtime performance would get exactly 1 ms for both values), with the frequency governor set to "performance".
 +
|-
 +
| Intel Core 2 Quad Q6600 || Gigabyte EP35C-DS3R|| 2.6.33.5-rt23 || [[User:rdoursenaud | Raphaël Doursenaud]] ||
 +
|-
 +
| Intel || Core 2 Quad Q9000 <br>HP DV7-2185dx|| 2.6.31-5-rt #6-Ubuntu SMP PREEMPT RT x86_64 || [[User:Dr. Tyrell | M A Chojnowski]] || Seems to work perfectly, but often seeing high userspace lock contentions.
 +
|-
 +
| Intel  || [http://www-307.ibm.com/pc/support/site.wss/quickPath.do?quickPathEntry=266874g IBM Thinkpad T43] Pentium M CPU 2 GHz  ||  2.6.23-rt3          || [[User:PhilK | PhilK]] || Avg. latency < 14us, worst case latency: < 32us
 +
|-
 +
| Intel  || Pentium 4 (M) 1.8 GHz      ||  2.6.29.1-rt7          || [[User:Matthias Kaehlcke | Matthias Kaehlcke]] ||
 +
|-
 +
| ARM9 (v4t)|| [http://www.atmel.com/dyn/products/tools_card.asp?family_id=605&family_name=AT91SAM+32%2Dbit+ARM%2Dbased+Microcontrollers&tool_id=3507 Atmel AT91RM9200-EK]  (See AT91-Notes) ||  2.6.23.12-rt14 || [[User:Remy | Remy Bohmer]] || worst case latency: < 300us (see Note 1)
 +
|-
 +
| ARM9 (v4t)|| [http://wiki.emqbit.com/free-ecb-at91 FREE_ECB_AT91]  (See AT91-Notes) ||  2.6.23.12-rt14 || Carlos Camargo ||
 +
|-
 +
| ARM9 (v4t)|| [http://www.cirrus.com/en/products/pro/detail/P1053.html Cirrus EP9301] ||  2.6.29.1-rt7 || [[User:Matthias Kaehlcke | Matthias Kaehlcke]]
 +
|-
 +
| ARM9 (v5tej)|| [http://www.atmel.com/dyn/products/tools_card.asp?family_id=605&family_name=AT91SAM+32%2Dbit+ARM%2Dbased+Microcontrollers&tool_id=3820 Atmel AT91SAM9261]  (See AT91-Notes) ||  2.6.24.7-rt27 || [[User:Remy | Remy Bohmer]] || worst case latency: < 150us (see Note 1)
 
|-
 
|-
| Intel  || Celeron D 2.93 Ghz      ||  2.6.20-rt8              || [[User:Remy | Remy Bohmer]] || Avg. latency < 10us, worst case latency: < 30us (see Note 1)
+
| ARM9 (v5tej)|| [http://linux.omap.com/ TI] [http://tree.celinuxforum.org/CelfPubWiki/OSK OMAP5912 OSK] ||  2.6.23-rt1 || [http://vger.kernel.org/vger-lists.html#linux-omap OMAP ML] || A small additional OMAP specific patch on top of -rt is needed. [http://marc.info/?l=linux-omap&m=119634477133936&w=2 See ML].
 
|-
 
|-
| Intel  || Core 2 Duo E6300        ||  2.6.20-rt8              || [[User:Remy | Remy Bohmer]] || Avg. latency < 10us, worst case latency: < 30us (see Note 1)
+
| ARM9 (v5tej)|| [http://www.ti.com/corp/docs/landing/davinci/index.html TI] [http://wiki.davincidsp.com/ DM6446 DaVinci] ||  2.6.23-rt1 || [http://linux.omap.com/pipermail/davinci-linux-open-source/ DaVinci ML] || A small additional DaVinci specific patch on top of -rt is needed. [http://linux.omap.com/pipermail/davinci-linux-open-source/2007-October/004283.html See ML].
 
|-
 
|-
| Intel  || Core 2 Duo E6600 2.4GHz ||  2.6.23-rc4-rt1          || [[User:Remy | Remy Bohmer]] || Avg. latency < 10us, worst case latency: < 30us (see Note 1)
+
| ARM9 (v5tej)|| [http://www.embeddedarm.com/products/board-detail.php?product=TS-7800 TS-7800] Marvell MV88F5182 ARM9 500MHz ||  2.6.29.3-rt13 || [[User:falstaff | Stefan Agner]] || worst case latency: < 250us, see [http://www.agner.ch/linuxrealtime agner.ch] (german)
 
|-
 
|-
| ARM9 (v4t)|| Atmel AT91RM9200-EK  (See AT91-Note 1) || 2.6.22-rt* to 2.6.23-rt4-rt1 || [[User:Remy | Remy Bohmer]] || worst case latency: < 500us (see Note 1)
+
| SH4 || [http://japan.renesas.com/fmwk.jsp?cnt=r2d_tools_product_landing.jsp&fp=/products/tools/os/Linux/sh_linux/r2d/ Renesas R2D/R2D+] SH7751R CPU || 2.6.21-rt2 and later || [http://vger.kernel.org/vger-lists.html#linux-sh linux-sh ML]
 
|-
 
|-
| ARM9 (v5t)|| Atmel AT91SAM9261-EK (See AT91-Note 1 and 2) || 2.6.22-rt* to 2.6.23-rt4-rt1 || [[User:Remy | Remy Bohmer]] || worst case latency: < 500us (see Note 1)
+
| XScale || IXP425 || 2.6.21.4-rt13 || [[User:Georgem | George McCollister]]
 
|-
 
|-
| ARM9 (v5tej)|| [http://linux.omap.com/ TI] [http://tree.celinuxforum.org/CelfPubWiki/OSK OMAP5912 OSK] || 2.6.23-rc8-rt1 || [http://linux.omap.com/mailman/listinfo/linux-omap-open-source OMAP ML] || A small additional OMAP specific patch on top of -rt is needed. See ML.
+
| ARM7TDMI || ml675003 || 2.6.26.6-rt11 || [[User:Georgem | George McCollister]]
 
|}
 
|}
''Note 1'': latency is defined as the time between the moment an interrupt occurs, and the moment the corresponding interrupt-thread gets running.
+
''Note 1'': latency is defined as the time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running.
  
''AT91-Note 1'': The following things can be troublesome on this architecture: (Work is in progress to fix these {by [[User:Remy | Remy Bohmer]]})
+
''AT91-Notes'': The following issues are known on this architecture:
* Serial port (DBGU) driver does illegal calls in Interrupt context. The interrupt handler has to be split up.
+
* Priority Inheritance Mutexes in userspace (PTHREAD_PRIO_INHERIT) only works since 2.6.23-rt1 with Glibc 2.5 and higher. Tested and stable with applications that match the memory locking scheme described on [[HOWTO:_Build_an_RT-application]].
* Priority Inheritance Mutexes in userspace (PTHREAD_PRIO_INHERIT) only works since 2.6.23-rc4-rt1 with Glibc 2.5 and higher. Tested and stable with applications that match the memory locking scheme described on [[HOWTO:_Build_an_RT-application]].
+
* Clocksource and clockevent implementations are available, and are in mainline since 2.6.24-rc4. (or see [http://maxim.org.za/at91_26.html AT91-patchset]) Tickless and HRT both work, but not using them due to very high CPU load compared to a ticking kernel on preempt-rt.
* Clocksource and clockevent implementations are available, but are not mainlined yet. (see [http://maxim.org.za/at91_26.html])
+
* GPIO Interrupt handling is not stable which causes missing GPIO interrupts, fixed by [http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/044088.html patch]. This patch is integrated in 2.6.23.11-rt14 and newer (Without this patch, the Ethernet adapter (DM9000) on AT91SAM9261-EK does not work in combination with PREEMPT-RT.)
* Only on a Hires-timer/tickless kernel: dummy 5ms timer requires 30% CPU-load with some applications. A application shows it all the time, or does not show it at all. Debugging with JTAG/ETM showed a strange looping behavior in kernel timer code independent from any system call. It seems a kernel bug triggered by some application behavior. The hires timer is currently based on a 32KHz clock, which is quite slow for hires, and maybe related to this problem.
+
''Note 2'': A wide range of systems and architectures (various x86, ARM, PPC, MIPS) with a CONFIG_PREEMPT_RT patched mainline kernel is continuously tested at the [http://osadl.org/QA OSADL QA Farm Realtime] under idle and load conditions. Both [http://www.osadl.org/QA-Farm-Continuous-real-time-monitorin.qa-farm-monitoring.0.html continuous latency monitoring data] and [http://www.osadl.org/Latency-plot-of-system-in-rack-1-slot-1.qa-latencyplot-r1s1.0.html cyclictest-generated latency plots] are available on-line and updated as soon as new data become available. Here latency is defined as the time between a timer interrupt occurs or, if scheduled by other reasons, a process is enqueued, and the moment the corresponding waiting user-space program is about to be switched to.
''AT91-Note 2'': DM9000 Ethernet driver is buggy. It does not work at all, and requires a redesign of the entire locking scheme.
+

Latest revision as of 05:33, 22 September 2012

Contents

[edit] The CONFIG_PREEMPT_RT Patch Set

The CONFIG_PREEMPT_RT patch set is maintained by a small group of core developers, led by Ingo Molnar. This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupt and software interrupts to kernel threads.

You can find now a detailed RT_PREEMPT_HOWTO on this page.

Paul McKenney has written a good CONFIG_PREEMPT_RT overview which is a good introduction to the changes introduced to the kernel by the CONFIG_PREEMPT_RT patch.

An overview about the various components of the CONFIG_PREEMPT_RT patch and their merge status into the mainline kernel is available here.

[edit] Download

The patch set is available here, as either a single monolithic patch, or in a broken-out tarball. See the announcement regarding the broken-out patch set.

The CONFIG_PREEMPT_RT patch set is also maintained in a git repo at kernel.org.

There is also an apt repository for Ubuntu with x86 precompiled kernel. You can find more information in this wiki page:

https://wiki.ubuntu.com/RealTime

[edit] Sending patches

Please send patches for the CONFIG_PREEMPT_RT Patch Set to LKML and put Ingo Molnar and Thomas Gleixner on CC.

Please do not send clocksource and clockevents related patches against the -rt patch. Make sure they apply against Linus' tree.

[edit] Platforms Tested and in Use with CONFIG_PREEMPT_RT

Processor Model #'s Kernel version(s) Contact(s) Comment(s)
Opteron IBM LS21, LS22, HS21XM, HS22x, 3455, 3550, 3650 2.6.16-rt22, 2.6.20-rt8 Theodore Ts'o, Darren Hart Systems have SMI Remediation support and handle ECC errors via the ibmprtm daemon.
Xeon IBM 6850-P4U 2.6.20-rt8, 2.6.21-rc6-rt0 Dave Sperry
Intel Xeon 2.4GHz with HT HP xw8000 2.6.29.3-rt12 Raphaël Doursenaud
AMD Opteron 175 ASUS A8N-SLI Premium 2.6.29.3-rt12 Raphaël Doursenaud
P4 Compaq Evo N610 2.6.16-rt22 Dave Sperry
P3 Celeron 1300 2.6.21.5-rt14 Oleksandr Natalenko
Intel Pentium Dual-Core T2330 2.6.29.1-rt4 Oleksandr Natalenko
Prescott PentiumD 3 GHz 2.6.22.6-rt9 Dmitry Pisklov
Intel Pentium 4 2.4 GHz 2.6.23.9-rt12 Jaswinder Singh
Intel Pentium 4 2.8 GHz with HT 2.6.23.9-rt12 Jaswinder Singh
Intel FSC D2151S Celeron D 2.93 Ghz 2.6.20-rt8 Remy Bohmer Avg. latency < 10us, worst case latency: < 30us (see Note 1)
Intel FSC D2151S Core 2 Duo E6300 2.6.20-rt8 Remy Bohmer Avg. latency < 10us, worst case latency: < 30us (see Note 1)
Intel Asus P5B Core 2 Duo E6600 2.4GHz 2.6.23-rc4-rt1 Remy Bohmer Avg. latency < 10us, worst case latency: < 30us (see Note 1)
Intel Core 2 Quad Q6600 2.6.24.7-rt27 User:Pauls Works ok, but frequency scaling has to be turned off for decent results. A task run at 1 kHz repetition rate with low load was found to be t-distributed with 4 degrees of freedom, with 1% value 0.9842 ms, 99% value 1.0103 ms (ideal realtime performance would get exactly 1 ms for both values), with the frequency governor set to "performance".
Intel Core 2 Quad Q6600 Gigabyte EP35C-DS3R 2.6.33.5-rt23 Raphaël Doursenaud
Intel Core 2 Quad Q9000
HP DV7-2185dx
2.6.31-5-rt #6-Ubuntu SMP PREEMPT RT x86_64 M A Chojnowski Seems to work perfectly, but often seeing high userspace lock contentions.
Intel IBM Thinkpad T43 Pentium M CPU 2 GHz 2.6.23-rt3 PhilK Avg. latency < 14us, worst case latency: < 32us
Intel Pentium 4 (M) 1.8 GHz 2.6.29.1-rt7 Matthias Kaehlcke
ARM9 (v4t) Atmel AT91RM9200-EK (See AT91-Notes) 2.6.23.12-rt14 Remy Bohmer worst case latency: < 300us (see Note 1)
ARM9 (v4t) FREE_ECB_AT91 (See AT91-Notes) 2.6.23.12-rt14 Carlos Camargo
ARM9 (v4t) Cirrus EP9301 2.6.29.1-rt7 Matthias Kaehlcke
ARM9 (v5tej) Atmel AT91SAM9261 (See AT91-Notes) 2.6.24.7-rt27 Remy Bohmer worst case latency: < 150us (see Note 1)
ARM9 (v5tej) TI OMAP5912 OSK 2.6.23-rt1 OMAP ML A small additional OMAP specific patch on top of -rt is needed. See ML.
ARM9 (v5tej) TI DM6446 DaVinci 2.6.23-rt1 DaVinci ML A small additional DaVinci specific patch on top of -rt is needed. See ML.
ARM9 (v5tej) TS-7800 Marvell MV88F5182 ARM9 500MHz 2.6.29.3-rt13 Stefan Agner worst case latency: < 250us, see agner.ch (german)
SH4 Renesas R2D/R2D+ SH7751R CPU 2.6.21-rt2 and later linux-sh ML
XScale IXP425 2.6.21.4-rt13 George McCollister
ARM7TDMI ml675003 2.6.26.6-rt11 George McCollister

Note 1: latency is defined as the time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running.

AT91-Notes: The following issues are known on this architecture:

  • Priority Inheritance Mutexes in userspace (PTHREAD_PRIO_INHERIT) only works since 2.6.23-rt1 with Glibc 2.5 and higher. Tested and stable with applications that match the memory locking scheme described on HOWTO:_Build_an_RT-application.
  • Clocksource and clockevent implementations are available, and are in mainline since 2.6.24-rc4. (or see AT91-patchset) Tickless and HRT both work, but not using them due to very high CPU load compared to a ticking kernel on preempt-rt.
  • GPIO Interrupt handling is not stable which causes missing GPIO interrupts, fixed by patch. This patch is integrated in 2.6.23.11-rt14 and newer (Without this patch, the Ethernet adapter (DM9000) on AT91SAM9261-EK does not work in combination with PREEMPT-RT.)

Note 2: A wide range of systems and architectures (various x86, ARM, PPC, MIPS) with a CONFIG_PREEMPT_RT patched mainline kernel is continuously tested at the OSADL QA Farm Realtime under idle and load conditions. Both continuous latency monitoring data and cyclictest-generated latency plots are available on-line and updated as soon as new data become available. Here latency is defined as the time between a timer interrupt occurs or, if scheduled by other reasons, a process is enqueued, and the moment the corresponding waiting user-space program is about to be switched to.

Personal tools