Will RT patches be merged in main line?
Hi everybody. Does the RT patches have been merged in the main line? or, They will be merged at all? I found the RT wiki at https://wiki.linuxfoundation.org/realtime/documentation/technical_details/st... but can't find if the patches were merged. Also I have some questions about RT benefits/drawbacks: The main benefit of RT kernel is that decreases the latency right? I read that it make all parts of the kernel preemptive, is this right? Why aren't these parts preemptive in the main line? What is the impact of making these parts preemptive? My general concept is that RT kernel has decreased latency, but increased overhead, ... is this right? Regards, -- “If you're going to try, go all the way. Otherwise, don't even start. ..." Charles Bukowski
On Mon, 28 May 2018 15:04:41 -0300, "Daniel." said:
Does the RT patches have been merged in the main line? or, They will be merged at all?
Much of it has already been merged, the patchset used to be like 3-4 times the size it is now.
The main benefit of RT kernel is that decreases the latency right?
The point isn't to decrease the latency - realtime is about guaranteeing a given process sufficient resources during each specified time interval. Lowering the latency to open up more time is just one way to achieve that.
I read that it make all parts of the kernel preemptive, is this right?
Well, that helps. If the CPU is currently busy in a non-preemptive chunk of code in a filesystem for the next 25ms, and an RT task needs at least 10ms of time during the next 20ms or a robot is going to crash into a wall and halt an assembly line, you have a problem.
Why aren't these parts preemptive in the main line? What is the impact of making these parts preemptive?
My general concept is that RT kernel has decreased latency, but increased overhead, ... is this right?
And that's why most of the rest isn't merged. It does add overhead and decreases total system throughput. And for 98% of the people who swear up and down they need RT for their gaming/music/whatever, it turns out that the current soft-RT code in the kernel is quite sufficient.
Could the patch be enabled by a kconfig option? Something like CONFIG_PREEMPT? On Mon, May 28, 2018, 8:48 PM <valdis.kletnieks@vt.edu> wrote:
On Mon, 28 May 2018 15:04:41 -0300, "Daniel." said:
Does the RT patches have been merged in the main line? or, They will be merged at all?
Much of it has already been merged, the patchset used to be like 3-4 times the size it is now.
The main benefit of RT kernel is that decreases the latency right?
The point isn't to decrease the latency - realtime is about guaranteeing a given process sufficient resources during each specified time interval. Lowering the latency to open up more time is just one way to achieve that.
I read that it make all parts of the kernel preemptive, is this right?
Well, that helps. If the CPU is currently busy in a non-preemptive chunk of code in a filesystem for the next 25ms, and an RT task needs at least 10ms of time during the next 20ms or a robot is going to crash into a wall and halt an assembly line, you have a problem.
Why aren't these parts preemptive in the main line? What is the impact of making these parts preemptive?
My general concept is that RT kernel has decreased latency, but increased overhead, ... is this right?
And that's why most of the rest isn't merged. It does add overhead and decreases total system throughput. And for 98% of the people who swear up and down they need RT for their gaming/music/whatever, it turns out that the current soft-RT code in the kernel is quite sufficient.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Valdis, thank you so much for that valuable answers!! There are some clusters running asterisk and they want RT kernels. I saw that there are RT kernels in the Centos repository so they may be easy to install, I guess that audio stuff need RT to avoid audio flickering, so I started to read about it. The technical stuff can be hard to grasp at first... thanks for helping me out! Cheers, 2018-05-28 21:48 GMT-03:00 <valdis.kletnieks@vt.edu>:
On Mon, 28 May 2018 15:04:41 -0300, "Daniel." said:
Does the RT patches have been merged in the main line? or, They will be merged at all?
Much of it has already been merged, the patchset used to be like 3-4 times the size it is now.
The main benefit of RT kernel is that decreases the latency right?
The point isn't to decrease the latency - realtime is about guaranteeing a given process sufficient resources during each specified time interval. Lowering the latency to open up more time is just one way to achieve that.
I read that it make all parts of the kernel preemptive, is this right?
Well, that helps. If the CPU is currently busy in a non-preemptive chunk of code in a filesystem for the next 25ms, and an RT task needs at least 10ms of time during the next 20ms or a robot is going to crash into a wall and halt an assembly line, you have a problem.
Why aren't these parts preemptive in the main line? What is the impact of making these parts preemptive?
My general concept is that RT kernel has decreased latency, but increased overhead, ... is this right?
And that's why most of the rest isn't merged. It does add overhead and decreases total system throughput. And for 98% of the people who swear up and down they need RT for their gaming/music/whatever, it turns out that the current soft-RT code in the kernel is quite sufficient.
-- “If you're going to try, go all the way. Otherwise, don't even start. ..." Charles Bukowski
participants (3)
-
Daniel. -
Demi Obenour -
valdis.kletnieks＠vt.edu