On Mon, May 4, 2026 at 9:04 PM Jan Kara <[email protected]> wrote: [...] > > > > BTW I'm not sure I quite understand Barry's priority inversion problem > > > since I'd expect all threads of a task to generally be treated with the > > > same priority... > > > > Exactly not. Maybe these slides[2] and this project[3] can give > > you a hint—they aim to standardize things on Linux by > > learning from Apple OS. Basically, tasks are classified > > into five types: > > > > USER_INTERACTIVE: Requires immediate response. > > USER_INITIATED: Tolerates a short delay, but must respond quickly still. > > UTILITY: Tolerates long delays, but not prolonged ones. > > BACKGROUND: Doesn’t mind prolonged delays. > > DEFAULT: System default behavior. > > Again, this is a clasification of tasks but not really of threads in a task > so at least for VMA lock there's no inversion so have?
I’m specifically referring to a task (i.e., a thread) when discussing scheduler context. It may be clearer to use the terms process and thread explicitly. In a typical process sharing an mm_struct, each thread can have a different priority. In an Android app, some threads handle the UI and require higher priority, such as the main thread and RenderThread; otherwise, frame drops may occur. The Linux scheduler can control scheduling policy and priority for each thread. Thanks Barry
