CONFIG PREEMPT RT Patch

From RTwiki
(Difference between revisions)
Jump to: navigation, search
m (Heading is Comment(s) and not Comments like with the other sections ;))
(Add OMAP5912 OSK)
Line 47: Line 47:
 
|-
 
|-
 
| 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]] || Achievable max. latency: < 500us
 
| 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]] || Achievable max. latency: < 500us
 +
|-
 +
| 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.
 
|}
 
|}
  

Revision as of 06:45, 3 October 2007

Contents

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.

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.

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.

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.

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

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 the latest -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.

Platforms Tested and in Use with CONFIG_PREEMPT_RT

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 Theodore Ts'o, Darren Hart
Xeon IBM 6850-P4U 2.6.20-rt8, 2.6.21-rc6-rt0 Dave Sperry
P4 Compaq Evo N610 2.6.16-rt22 Dave Sperry
P3 Celeron 1300 2.6.21.5-rt14 Oleksandr Natalenko
Prescott PentiumD 3 GHz 2.6.22.6-rt9 Dmitry Pisklov
Intel Pentium 4 CPU 2.4 GHz 2.6.23-rc8-rt1 Jaswinder Singh
Intel Core 2 Duo E6300/E6400 2.6.20-rt8 Remy Bohmer Achievable max. latency: During DMA Bus-Mastering < 30us, else < 10us
Intel Core 2 Duo E6600 2.4GHz 2.6.23-rc4-rt1 Remy Bohmer Achievable max. latency: During DMA Bus-Mastering < 30us, else < 10us
ARM9 (v4t) Atmel AT91RM9200-EK (See AT91-Note 1) 2.6.22-rt* to 2.6.23-rt4-rt1 Remy Bohmer Achievable max. latency: < 500us
ARM9 (v5t) Atmel AT91SAM9261-EK (See AT91-Note 1 and 2) 2.6.22-rt* to 2.6.23-rt4-rt1 Remy Bohmer Achievable max. latency: < 500us
ARM9 (v5tej) TI OMAP5912 OSK 2.6.23-rc8-rt1 OMAP ML A small additional OMAP specific patch on top of -rt is needed. See ML.

AT91-Note 1: The following things can be troublesome on this architecture: (Work is in progress to fix these {by Remy Bohmer})

  • 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-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, but are not mainlined yet. (see [1])
  • 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.

AT91-Note 2: DM9000 Ethernet driver is buggy. It does not work at all, and requires a redesign of the entire locking scheme.

Personal tools