Messages in this thread |  | | Subject | Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems | From | Tetsuo Handa <> | Date | Mon, 16 Mar 2020 19:04:44 +0900 |
| |
On 2020/03/16 18:31, Michal Hocko wrote: >> What happens if the allocator has SCHED_FIFO? > > The same thing as a SCHED_FIFO running in a tight loop in the userspace. > > As long as a high priority context depends on a resource held by a low > priority task then we have a priority inversion problem and the page > allocator is no real exception here. But I do not see the allocator > is much different from any other code in the kernel. We do not add > random sleeps here and there to push a high priority FIFO or RT tasks > out of the execution context. We do cond_resched to help !PREEMPT > kernels but priority related issues are really out of scope of that > facility. >
Spinning with realtime priority in userspace is a userspace's bug. Spinning with realtime priority in kernelspace until watchdog fires is a kernel's bug. We are not responsible for userspace's bug, and I'm asking whether the memory allocator kernel code can give enough CPU time to other threads even if current thread has realtime priority.
|  |