+ sched division On 2022-03-10 18:23:26 [-0800], Andrew Morton wrote: > On Thu, 10 Mar 2022 10:22:12 -0300 Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > > On systems that run FIFO:1 applications that busy loop, > > any SCHED_OTHER task that attempts to execute > > on such a CPU (such as work threads) will not > > be scheduled, which leads to system hangs. … > > Permitting a realtime thread to hang the entire system warrants a > -stable backport, I think. That's just rude. I'm not sure if someone is not willingly breaking the system. Based on my experience, a thread with an elevated priority (that FIFO, RR or DL) should not hog the CPU. A normal user (!root && !CAP_SYS_NICE) can't increase the priority of the task. To avoid a system hangup there is sched_rt_runtime_us which ensures that all RT threads are throttled once the RT class exceed a certain amount of runtime. This has been relaxed a little on systems with more CPUs so that the RT runtime can be shared but this sharing (RT_RUNTIME_SHARE) has been disabled by default a while ago. That safe switch (sched_rt_runtime_us) can be disabled and is usually disabled on RT system since the RT tasks usually run longer especially in corner cases. People often isolate CPUs and have busy-loop tasks running with SCHED_OTHER given that there is nothing else going on there will be no preemption. In this case, the worker would preempt the task. In this scenario I _can_ understand that one wants to avoid that preemption and try things differently like this patch suggests. We can even offload RCU thread from isolated CPUs. But I wouldn't say this requires a backport because there is way for a RT thread, that claims 100% of the CPU, to break the system. Sebastian
