Messages in this thread | | | Date | Fri, 11 Mar 2022 16:40:43 -0800 | From | Andrew Morton <> | Subject | Re: [patch v5] mm: lru_cache_disable: replace work queue synchronization with synchronize_rcu |
| |
On Fri, 11 Mar 2022 09:35:49 +0100 Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> + 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@redhat.com> 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.
Does all this apply if the kernel is non-preemptible?
Marcelo, do you know how the offending system bypassed the failsafe?
| |