2 ms·

Glad to see someone with industrial experience on realtime processing to respond. > a complete misunderstanding of the role of nice values for scheduling (hint

Glad to see someone with industrial experience on realtime processing to respond. > a complete misunderstanding of the role of nice values for scheduling (hint; it's only useful for altering the behavior of non-RT threads, which means threads that do not have hard or semi-hard timing deadlines). I suspect you're misreading the quoted documentation, I believe the quoted documentation is fine. To recite, "only the IO threads of PulseAudio are made real-time. The controlling thread is left a normally scheduled thread. Thus enabling the high-priority option is orthogonal (to SCHED_FIFO)". Nice is applied to the controller responsible for other tasks, SCHED_FIFO is applied to the I/O threads, independently. > On modern Linux systems, it is impossible for SCHED_FIFO to cause system lockups. [...] so even a SCHED_FIFO thread that runs "while (true){}" will not be allowed to use 100% of a core's cycles. Really? The rtkit documentation mentioned, > If processes that have real-time scheduling privileges enter a busy loop they can freeze the entire the system. To make sure such run-away processes cannot do this RLIMIT_RTTIME has been introduced. Being a per-process limit it is however easily cirumvented by combining a fork bomb with a busy loop. > RealtimeKit hands out RT scheduling to specific threads that ask for it -- but only to those and due to SCHED_RESET_ON_FORK it can be sure that this won't 'leak'. > In contrast to RLIMIT_RTPRIO, the RealtimeKit logic makes sure that only a certain number of threads can be made realtime, per user, per process and per time interval. So "while (true){}" won't lock your system up, but "while (true) { fork(); }" certainly will, so the rational of only using SCHED_FIFO on trusted processes is reasonable. I think it's still true. Is it?

PaulDavisThe1st 7y ago
No, it's not still true, and rtkit is just a convenience item that has nothing to do with core kernel policy. The use of nice to try to adjust scheduling of audio apps (the entire application or specific threads) is completely off-base. If you use SCHED_OTHER, you're making a declaration that timing is not important. You can bump the nice value of a SCHED_OTHER thread, and that will change its behavior among the pool of the other SCHED_OTHER threads, but that's almost never useful in an audio app. Now, ionice is another (and more complex) story ...
- segfaultbuserr 7y ago
  > No, it's not still true The point of rtkit is creating a convenient framework to enforce SCHED_RESET_ON_FORK and rate-throttling in a single place. So if I'm interpreting your comment correctly, running a "while (true) { fork(); }", even without restrictions of SCHED_RESET_ON_FORK, will not lock the system up in a modern system? Is it correct? > The use of nice to try to adjust scheduling of audio apps (the entire application or specific threads) is completely off-base. I think the renicing mechanism of "high-priority=" was historical, introduced to PulseAudio long before the system resource limit like RLIMIT_RTPRIO, or the rtkit framework has been put into place. As another document mentioned, g > To minimize the risk of drop-outs during playback it is recommended to run PulseAudio with real-time schedulin [...] Alternatively, if the risk of locking up the machine is considered too big to enable real-time scheduling, high-priority scheduling can be enabled [...] So while renicing is still here, PulseAudio prefers SCHED_FIFO nowadays, and the renice is only a fallback. So, can you point out where exactly is wrong in the first documentation I quoted in the first comment? Certainly, the paragraph, "high-priority= Renice the daemon after startup to become a high-priority process. This a good idea if you experience drop-outs during playback" is outdated, but if one removes the word "Renice", and moves this paragraph from "high-priority=" to "realtime-scheduling=", it's still correct.
PaulDavisThe1st 7y ago
Can't reply to your deepest response. Basically, read: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/real_time_throttling https://access.redhat.com/documentation/en-us/red_hat_enterp... (This is from RH, but the kernel params are generic) Again, RTKit is a convenience wrapper, nothing more or less. It runs with sufficient priviledge to ask for SCHED_FIFO, which by default is not permitted. The more conventional approach is to create a user group and use PAM or equivalent to set the rt priority limit for that group, thus allowing any user in the group to run any app that can then ask for SCHED_FIFO with prio up to the limit. RTKit was created by Lennart to avoid this type of sysconfig (in favor of a different type of sysconfig). You're mistaken about the historical ordering of things too. SCHED_FIFO was available long before PulseAudio or RTKit was created. Yes, you could shuffle the text around as you suggest, but that's far from a "trivial" edit. It's basically equivalent to saying "yeah, the old doc was basically totally wrong, here's a correct version" :)
- segfaultbuserr 7y ago
  > Can't reply to your deepest response. Pro-Tip: Hacker News has a "new comment cool-off timer", it gives a minute or two before allowing a comment to be answered. It gives a chance for the poster to edit the comment. Just relax when you cannot see a reply button. > Basically, read: https://access.redhat.com/documentation/en-us/red_hat_enterp.. https://access.redhat.com/documentation/en-us/red_hat_enterp.... (This is from RH, but the kernel params are generic) I see. "The default values for the Real-time throttling mechanism define that 95% of the CPU time can be used by real-time tasks. The remaining 5% will be devoted to non-realtime tasks (tasks running under SCHED_OTHER and similar scheduling policies). It is important to note that if a single real-time task occupies that 95% CPU time slot, the remaining real-time tasks on that CPU will not run. The remaining 5% of CPU time is used only by non-realtime tasks". So a fork bomb is as safe is an empty loop (at least from a scheduling prospectively), as long as a strict limit is set. I have noted it down. > Yes, you could shuffle the text around as you suggest, but that's far from a "trivial" edit. It's basically equivalent to saying "yeah, the old doc was basically totally wrong, here's a correct version" :) Okay, the main documentation for "man pulseaudio" was a bit better, > To minimize the risk of drop-outs during playback it is recommended to run PulseAudio with real-time scheduling if the underlying platform supports it. This decouples the scheduling latency of the PulseAudio daemon from the system load a You see, here it mentions real-time scheduling, not high-priority scheduling in "man pulse-daemon.conf". So I guess the explanation of " high-priority=" was more or less untouched since 2008, but the code kept moving on. > You're mistaken about the historical ordering of things too. SCHED_FIFO was available long before PulseAudio or RTKit was created. I meant the renicing mechanism was in PulseAudio before RLIMIT_RTPRIO, or the rtkit framework. I didn't say a word about SCHED_FIFO, which was indeed POSIX, but less useful without later improvement on scheduling policies. Thanks for your patience and answers, all my questions have been explained.

PaulDavisThe1st 7y ago

No, it's not still true, and rtkit is just a convenience item that has nothing to do with core kernel policy. The use of nice to try to adjust scheduling of audio apps (the entire application or specific threads) is completely off-base. If you use SCHED_OTHER, you're making a declaration that timing is not important. You can bump the nice value of a SCHED_OTHER thread, and that will change its behavior among the pool of the other SCHED_OTHER threads, but that's almost never useful in an audio app. Now, ionice is another (and more complex) story ...

segfaultbuserr 7y ago
> No, it's not still true The point of rtkit is creating a convenient framework to enforce SCHED_RESET_ON_FORK and rate-throttling in a single place. So if I'm interpreting your comment correctly, running a "while (true) { fork(); }", even without restrictions of SCHED_RESET_ON_FORK, will not lock the system up in a modern system? Is it correct? > The use of nice to try to adjust scheduling of audio apps (the entire application or specific threads) is completely off-base. I think the renicing mechanism of "high-priority=" was historical, introduced to PulseAudio long before the system resource limit like RLIMIT_RTPRIO, or the rtkit framework has been put into place. As another document mentioned, g > To minimize the risk of drop-outs during playback it is recommended to run PulseAudio with real-time schedulin [...] Alternatively, if the risk of locking up the machine is considered too big to enable real-time scheduling, high-priority scheduling can be enabled [...] So while renicing is still here, PulseAudio prefers SCHED_FIFO nowadays, and the renice is only a fallback. So, can you point out where exactly is wrong in the first documentation I quoted in the first comment? Certainly, the paragraph, "high-priority= Renice the daemon after startup to become a high-priority process. This a good idea if you experience drop-outs during playback" is outdated, but if one removes the word "Renice", and moves this paragraph from "high-priority=" to "realtime-scheduling=", it's still correct.

PaulDavisThe1st 7y ago

Can't reply to your deepest response. Basically, read: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/real_time_throttling https://access.redhat.com/documentation/en-us/red_hat_enterp... (This is from RH, but the kernel params are generic) Again, RTKit is a convenience wrapper, nothing more or less. It runs with sufficient priviledge to ask for SCHED_FIFO, which by default is not permitted. The more conventional approach is to create a user group and use PAM or equivalent to set the rt priority limit for that group, thus allowing any user in the group to run any app that can then ask for SCHED_FIFO with prio up to the limit. RTKit was created by Lennart to avoid this type of sysconfig (in favor of a different type of sysconfig). You're mistaken about the historical ordering of things too. SCHED_FIFO was available long before PulseAudio or RTKit was created. Yes, you could shuffle the text around as you suggest, but that's far from a "trivial" edit. It's basically equivalent to saying "yeah, the old doc was basically totally wrong, here's a correct version" :)

segfaultbuserr 7y ago
> Can't reply to your deepest response. Pro-Tip: Hacker News has a "new comment cool-off timer", it gives a minute or two before allowing a comment to be answered. It gives a chance for the poster to edit the comment. Just relax when you cannot see a reply button. > Basically, read: https://access.redhat.com/documentation/en-us/red_hat_enterp.. https://access.redhat.com/documentation/en-us/red_hat_enterp.... (This is from RH, but the kernel params are generic) I see. "The default values for the Real-time throttling mechanism define that 95% of the CPU time can be used by real-time tasks. The remaining 5% will be devoted to non-realtime tasks (tasks running under SCHED_OTHER and similar scheduling policies). It is important to note that if a single real-time task occupies that 95% CPU time slot, the remaining real-time tasks on that CPU will not run. The remaining 5% of CPU time is used only by non-realtime tasks". So a fork bomb is as safe is an empty loop (at least from a scheduling prospectively), as long as a strict limit is set. I have noted it down. > Yes, you could shuffle the text around as you suggest, but that's far from a "trivial" edit. It's basically equivalent to saying "yeah, the old doc was basically totally wrong, here's a correct version" :) Okay, the main documentation for "man pulseaudio" was a bit better, > To minimize the risk of drop-outs during playback it is recommended to run PulseAudio with real-time scheduling if the underlying platform supports it. This decouples the scheduling latency of the PulseAudio daemon from the system load a You see, here it mentions real-time scheduling, not high-priority scheduling in "man pulse-daemon.conf". So I guess the explanation of " high-priority=" was more or less untouched since 2008, but the code kept moving on. > You're mistaken about the historical ordering of things too. SCHED_FIFO was available long before PulseAudio or RTKit was created. I meant the renicing mechanism was in PulseAudio before RLIMIT_RTPRIO, or the rtkit framework. I didn't say a word about SCHED_FIFO, which was indeed POSIX, but less useful without later improvement on scheduling policies. Thanks for your patience and answers, all my questions have been explained.