Manjaro realtime kernels


Thanks to @crazyg4merz’s initiative and research we have been working recently on a Manjaro realtime kernel, aimed at providing extremely low latency times.
It’s not necessarily something you’d favour for your normal everyday use, but mainly in an audio production environment an rt-kernel is definitely what you’d want to use, as Budiman demonstrates in his video:

During the last weeks we have been starting off from basekernel linux46 with linux-rt-manjaro, which is meanwhile available on our testing branch.
Since the rt-patch updated to 4.6.5-rt8 though, this kernel loses support of the virtualbox extramodules temporarily (until Oracle decides to update their code to the latest kernel development).

For that reason we have now decided to provide another rt-version, based on LTS kernel linux44 and called this one linux-rt-lts-manjaro. This one is now also available on the unstable branch and comes with all extramodules, except for the rt-incompatible ones nvidia-340xx and spl/zfs.

Please test and give us feedback!

Manjaro is very impressive. But long term
A realtime kernel for Manjaro
Why isn't bfq I/O still in mainline kernel?
New to the forum, introduce yourself
Questions from someone considering Manjaro

Also thanks to @oberon, @philm, and @Kirek for their help along the way. :slight_smile: Really learned from you guys.


Both new kernels can now also be installed via manjaro-settings-manager :slight_smile:

Thank you once more, @Kirek!


I think we have so many kernel to deal with, maybe just 3 or 4 enough and should be one fine well studied like your works.


Well, most of the kernels are normally maintained. Real-Time kernels however need more insight. That is why we only support x86_64 for them. We have now 14 different kernel series for 64-bit in Manjaro Linux. This is a huge collection and is one of the heartstones of Manjaro.

Not every distribution provides such a collection. However, some of them are marked as end of life (EOL), which means we will remove them soon.

It is like desktop environments. Not everybody uses them all. Choose which kernel works best for your hardware. The kernel is the core driver. If you never try some other series you might not even know what power you might miss on your system.


Great work, congratulations to the developers, it is a great initiative :smiley:


The latest update of linux-rt-manjaro 4.6.5_rt10 has the brand new kernel parameter NO_HZ_FULL set.
More explanations about this feature can be found here


I haven’t test it yet. Being busy for a while, but the lts version is still my daily driver though. Once in a while it just stuck during boot up but a simple reset fixes that problem. Haven’t got a time to find the problem though. Do you find anything @oberon?


Works nice here. Only around 20 timer interrupts per second on CPUs 1-3, while CPU0 is doing ~1200/s.

# journalctl -b | grep HZ
Aug 10 13:01:03 sumomo kernel: NO_HZ: Clearing 0 from nohz_full range for timekeeping
Aug 10 13:01:03 sumomo kernel: NO_HZ: Full dynticks CPUs: 1-3.

# watch -n1 -d "cat /proc/interrupts|egrep 'LOC|CPU'"
            CPU0       CPU1       CPU2       CPU3       
 LOC:    2075104     133789     120760     114543   Local timer interrupts

Took some info from this blog-post.

Thank you for the great work.


So what does that mean?
Can you explain to me? Thanks for testing out our kernel. Appreciate it :slight_smile:


I think Eder describes things elegantly on his blogpost:

When the tick fires (as often as every millisecond, based on value of
CONFIG_NO_HZ), it will get scheduled ahead of whatever’s currently
running on a CPU core. In other words, whatever was running (with all of
it’s valuable data cache-hot) will be interrupted by the tick. The CPUs
L1 instruction and data caches (the smallest yet fastest) are

Additionally, I’d like to cite the doc @oberon posted, that summarizes the motivation quite nicely:

The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
sending scheduling-clock interrupts to CPUs with a single runnable task,
and such CPUs are said to be “adaptive-ticks CPUs”. This is important
for applications with aggressive real-time response constraints because
it allows them to improve their worst-case response times by the maximum
duration of a scheduling-clock interrupt. It is also important for
computationally intensive short-iteration workloads: If any CPU is
delayed during a given iteration, all the other CPUs will be forced to
wait idle while the delayed CPU finishes. Thus, the delay is multiplied
by one less than the number of CPUs. In these situations, there is
again strong motivation to avoid sending scheduling-clock interrupts.

These excerpts sum its use up :slight_smile:


So do you have any performance dropping issue? Because it interrupts other processes right?


Ideally, fewer ticks should indeed improve performance (at least of big/demanding tasks and real-time). Theoretically, there are some drawbacks, as this does not come for free (kernel/user transitions are somewhat slower [see Known Issues on ] ).

Perceivable? Definitively not.
Measurable? Possibly. But I did not run any extended benchmarks to test that. But it handles some stress nicely.


WOW !! This is what I’m looking for. I do little audio production before in KX Studio which is ubuntu based distro. I’m very happy if Manjaro can do this too. :smiley:


Both rt-kernels have meanwhile arrived on the testing branch:
linux-rt-manjaro 4.6.5_rt10 (including NO_HZ_FULL)
and linux-rt-lts-manjaro 4.4.15_rt23, based on linux44, which does support virtualbox extramodules but doesn’t provide the NO_HZ_FULL option.


@deemde Thanks for the clarification. :slight_smile:
Now what do you think if we implement CONFIG_NO_HZ_FULL in both kernel @oberon?

Nice, now our effort is worth it. :slight_smile:


Afaik it’s not availble in the linx44 series :wink:


Okay, I forgot that was a new thing :blush:


I want to thank you for your work. I already asked myself how to install a RT-Kernel in Manjaro, since I’m a musician. And now I know that it just didn’t exist yet. :slight_smile:
I didnt’t try the Kernel yet, because I want to spend some money for a new Notebook for doing my own recording and production stuff in a few months. I already chose one, but can’t afford it instantly :frowning:
But maybe I’ll become too curious before I have thw new Notebook and try it on the old one. :smiley:

Thanks for giving us the possibility!


Show us your creation once you’re done. :slight_smile: