Of course every user can create his own kernel coniguration or even modify the Linux kernel in any way he wants. But if there is any problem he's beeing left alone. I think it would be much better to have a default kernel configuration which at least provides simple PREEMPT support. That might help people to fight against most simple latency problems.
Am Mittwoch, 26. Februar 2014 13:21:58 UTC+1 schrieb Charles Steinkuehler: > > There's PREEMPT_RT, and there's PREEMPT. *ALL* Linux kernels have > PREEMPT available now. It sounds like you're just complaining that the > kernel was built with a different option than you want. Simply rebuild > the kernel and set CONFIG_PREEMPT instead of CONFIG_PREEMPT_VOLUNTARY: > > > https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patches/defconfig#L467 > > > Or if you're requesting a change to the default kernel configuration, > you're going about it in kind of a round-about way. > > On 2/26/2014 3:11 AM, quik...@gmail.com <javascript:> wrote: > > Hi Charles, > > > > the PREEMPT_RT patches can now be applied to the BBB kernel. As John3909 > > suggested there is a ready to use patch script available from OSADL. > > Compiling a BBB kernel 3.12.10-rt15 is quick and easy. But > unfortunately, > > it requires the use of kernel 3.12.x which causes problems with the GPMC > as > > documented at > > > https://groups.google.com/forum/#!searchin/beagleboard/gpmc/beagleboard/KOHLJI1NUTA/8wrsV_ZodDUJ. > > > > > > In the default BBB kernel there is no "built-in" PREEMPT option. Without > > that Linux cannot be used for any time critical application and > latencies a > > very bad. Contrary to that the Raspberry PI's default kernel had PREEMPT > > activated from the very beginning and does provide some form of > determinism > > out of the box. > > > > What we need is a default kernel that has at least support for the > simple > > PREEMPT option. Yes, there are custom drivers and they need to fit into > the > > concept. But that is working perfectly for the Raspberry PI which > > definitely uses custom firmware and drivers. The BBB seems to be far > behind > > that. > > > > > > > > Am Montag, 24. Februar 2014 18:30:51 UTC+1 schrieb Charles Steinkuehler: > >> > >> 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, quik...@gmail.com <javascript:> 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 quik...@gmail.com 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 > >> cha...@steinkuehler.net <javascript:> > >> > > > > > -- > Charles Steinkuehler > cha...@steinkuehler.net <javascript:> > -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
