> 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 answe

> 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.