Does the PREEMPT_RT patch (real-time kernel) have any benefit for regular desktop users?
Add a comment |
2 Answers
I don't think so. The patch seems to provide real-time scheduling which is very important for some enviroments (planes, nuclear reactors etc.) but overkill for regular desktop. The current kernels however seems to be enough "real-time" and "preemptive" for regular desktop users[1].
It may be useful if you work with high quality audio recording and playing in which even small amount of time may dramatically reduce the quality.
[1] Technically both are 0/1 features but I guess it is clear what I mean ;)
- can we change kernel scheduler on the fly, just like cpu_governor?uray– uray2010-09-07 12:51:34 +00:00Commented Sep 7, 2010 at 12:51
- you cannot change kernel scheduler like CFS or BFS. However you CAN change scheduling properties by
schedtoolon the fly (priority, make process as interactive/batch etc.)Maja Piechotka– Maja Piechotka2010-09-07 17:30:43 +00:00Commented Sep 7, 2010 at 17:30
I'm guessing you misunderstand the concept of 'real-timeness'. If not, sorry, but it happens a lot, and I thought I'd throw a little clarification in here.
The main point of a real-time kernel is to serve requests within a predictable deadline. That does not necessarily mean faster than a 'normal' kernel. So for desktop systems, a preemptive kernel is good, a real-time kernel much less so.
- I do understand a little bit about real-time application, and I did developed soft-realtime applications for embedded systems, and I understood that it won't give "faster" experience, but in theory it should give more "responsive" user interactions, isn't that true?uray– uray2010-09-13 15:36:13 +00:00Commented Sep 13, 2010 at 15:36
- Not necessarily. As far as I understand it, it will give you applications with a predictable response time.wzzrd– wzzrd2010-09-13 19:06:55 +00:00Commented Sep 13, 2010 at 19:06
- And since the total processing power of a CPU is constant (simplifying a bit), and context switches cost CPU power, it's likely that some things could become slower (but still responsive to a certain response time).Alexios– Alexios2012-06-07 09:12:39 +00:00Commented Jun 7, 2012 at 9:12