For the most part, RT shouldn’t break anything. As you can see from the 
rt-kernel notes below, the rt-kernel is simply breaking up the the big kernel 
lock by replacing spinlocks with mutexes so that code can be preempted. Unless 
there is some other code that is causing preemption, your app should not run 
any slower. It is true that latency and throughput have an inverse 
relationship, but that is only true if you are using an app that requires 
reduced latencies and only then will you see throughput slow down. 
How does the CONFIG_PREEMPT_RT patch work?
The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic 
is done with:
Making in-kernel locking-primitives (using spinlocks 
<http://en.wikipedia.org/wiki/Spinlock>) preemptible though reimplementation 
with rtmutexes.
Critical sections protected by i.e. spinlock_t and rwlock_t are now 
preemptible. The creation of non-preemptible sections (in kernel) is still 
possible with raw_spinlock_t (same APIs like spinlock_t).
Implementing priority inheritance 
<https://rt.wiki.kernel.org/index.php/Priority_inheritance> for in-kernel 
spinlocks and semaphores. For more information on priority inversion 
<https://rt.wiki.kernel.org/index.php/Priority_inversion> and priority 
inheritance please consult Introduction to Priority Inversion.
Converting interrupt handlers into preemptible kernel threads: The RT-Preempt 
patch treats soft interrupt handlers in kernel thread context, which is 
represented by a task_struct like a common user space process. However it is 
also possible to register an IRQ in kernel context.
Converting the old Linux timer API into separate infrastructures for high 
resolution kernel timers plus one for timeouts, leading to user space POSIX 
timers with high resolution.


Regards,
John




> On Feb 15, 2016, at 3:32 PM, William Hermans <[email protected]> wrote:
> 
> RT plays with a lot of things to try and make the kernel tasks operate
> in Real Time...  It's a work and progress, looking at your dmesg, your
> camera driver had issues with it.  It was still 50/50 that it would
> help, we just got lucky..
> 
> More than that, I seriously doubt an RT kernel is going to help with this 
> type of situation. RT kernels are meant to help with real time situations, 
> and camera applications do not to my knowledge do not need, or even want real 
> time operation. In fact, I do believe if you do the research a real time 
> kernel can potentially slow down disk access, disk caching, and the like.
> 
> On Mon, Feb 15, 2016 at 4:17 PM, Robert Nelson <[email protected] 
> <mailto:[email protected]>> wrote:
> On Mon, Feb 15, 2016 at 5:09 PM, joelk <[email protected] 
> <mailto:[email protected]>> wrote:
> > @John: Yes, I will try a Debian image, after I try the kernel Robert
> > suggested.  Maybe I can give him some useful feedback.
> >
> > Also, I'd rather not bog things down with a desktop environment that I don't
> > need.  The latest Jessie image seems to have LXDE and enough other stuff to
> > fill up 4GB.  Is there a console image of Jessie hidden away somewhere?
> >
> > @Robert:
> > Before switching the kernel I ran apt-get update and apt-get upgrade.  Hit a
> > little snag at the end of the update.  I just want to document this here in
> > case things get worse:
> >
> >> Processing triggers for initramfs-tools
> >> (0.103ubuntu4.2-1rcnee1~bpo1404+20151007+1) ...
> >> update-initramfs: Generating /boot/initrd.img-4.4.0-armv7-x3
> >> WARNING: missing /lib/modules/4.4.0-armv7-x3
> >> Device driver support needs thus be built-in linux image!
> >> depmod: ERROR: could not open directory /lib/modules/4.4.0-armv7-x3: No
> >> such file or directory
> >> depmod: FATAL: could not search modules: No such file or directory
> >> depmod: WARNING: could not open
> >> /tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.order: No such
> >> file or directory
> >> depmod: WARNING: could not open
> >> /tmp/mkinitramfs_T9g7pP/lib/modules/4.4.0-armv7-x3/modules.builtin: No such
> >> file or directory
> 
> That's nothing to worry about, it's dual board base image,
> 4.4.0-armv7-x3 is the kernel for the beagleboard xM...
> 
> >>
> >
> > apt-get does not offer to upgrade anything else at this point.  Rebooted OK.
> > /boot contains initrd.img-4.4.0-armv7-x3 with size == 2122190 and
> > timestamped just 10 minutes ago.  I don't know what's missing or how
> > important it is.
> >
> > Before changing kernel, uname -r gives 4.1.15-ti-rt-r40
> > Updating the kernel was uneventful.
> > Rebooted OK.
> >
> > Robert, you're a hero.  motion runs & its http server sends a stream over
> > the web.  same goes for koudevoeten, although I had to kill -9 to stop it.
> > So far so good.
> >
> > So please tell me -- what is this evil RT patchset that's been causing so
> > much grief?  And how will I know which kernels have it and which don't?
> > Which Debian images (preferable console-only) can I use?
> 
> RT plays with a lot of things to try and make the kernel tasks operate
> in Real Time...  It's a work and progress, looking at your dmesg, your
> camera driver had issues with it.  It was still 50/50 that it would
> help, we just got lucky..
> 
> Regards,
> 
> 
> --
> Robert Nelson
> https://rcn-ee.com/ <https://rcn-ee.com/>
> 
> --
> For more options, visit http://beagleboard.org/discuss 
> <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] 
> <mailto:beagleboard%[email protected]>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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] 
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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/d/optout.

Reply via email to