Be careful of applying x86 experience to the ARM. PREEMPT_RT requires well written driver code that is "high-performance SMP friendly" in order to run well. PREEMPT_RT on the x86 works so well because a *LOT* of smart people have been working very hard to get maximum performance out of the multi-core CPUs that ship in virtually every new system these days.
ARM systems, on the other hand, are riddled with vendor supplied device drivers that hopefully work well and if you're lucky weren't written by the summer intern. The ARM situation _is_ getting better, but IMHO PREEMPT_RT on the ARM is still hit-and-miss. It will work quite well in some situations, and have horrible performance on similar but not-quite-identical setups. That said, while Xenomai offers better bounded performance figures, PREEMPT_RT is perfectly fine for a large class of problems and as you mentioned you get access to the full suite of Linux services. Unless I missed it, you never said exactly _what_ you are trying to do, you simply started off by complaining that the kernel wasn't configured by default the way that you wanted it. So go compile a kernel, and if you're asking for advice, please provide specifics on exactly what you are trying to do and any limitations on your solution space. Also, make sure you test any PREEMPT_ based kernel to determine your worst-case performance. When I was looking into this some time ago, the PREEMPT_RT patches wouldn't even apply to the BeagleBone kernel, and using the built-in CONFIG_PREEMPT setting I was seeing latencies in the hundreds of mS (yes that is tenths of seconds!). I believe things have gotten much better, but you'll need to test to know if your setup will provide the performance you require. On 2/24/2014 10:47 AM, [email protected] wrote: > Only PREEMPT_RT allows access to the full Linux functionality. Xenomai uses > a dual kernel concept which is very limited. All custom device drivers need > be design to fit into the Xenomai concept which makes things even worse. > The performance gain of Xenomai compared to that of PREEMPt_RT is > negligible in most cases. > > > Am Freitag, 21. Februar 2014 12:27:01 UTC+1 schrieb Giuseppe Iellamo: >> >> Or just try Xenomai... >> >> https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone39-xenomai >> >> >> Il giorno venerdì 21 febbraio 2014 11:03:24 UTC+1, David Goodenough ha >> scritto: >>> >>> On Friday 21 February 2014 00:20:39 [email protected] wrote: >>>> I am trying to figure out how to create a kernel for the BBB that >>> supports >>>> PREEMPT_RT. It's kind of strange that the BBB's default kernel does not >>>> even have PREEMPT activated. Such a board doesn't fit to many embedded >>>> applications where we need at least some kind of determinism. It is >>> even >>>> worse, that nobody seems to care about this problem. Contrary to that, >>> the >>>> Raspberry PI's standard kernel has PREEMPT activacted from the very >>>> beginning. >>>> >>>> I have tested Robert Nelsons kernel 3.8.13-r9 >>>> (https://github.com/beagleboard/kernel/tree/3.8-rt). It does not have >>>> PREEMPT_RT activated by default. When doing so, it does not boot. But >>>> activating PREEMPT does work. However, development of this branch has >>>> stopped several months ago. The official source for RT Linux (3.8.13) >>> has >>>> evolved since then. Meanwhile there's an rt17 patch set >>>> (https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/). Did >>> anybody >>>> give this a try? Does it work with the BBB? >>> Surely the point of the Beaglebone, or rather its processor, is that you >>> do not need to put the time critical bits on the main processor, you put >>> them in the PRUSS processors. >>> >>> David >>> >> > -- Charles Steinkuehler [email protected] -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
