Thread or Process?

Posted Jul 2, 2021 18:40 UTC (Fri) by glenn (subscriber, #102223)
Parent article: Core scheduling lands in 5.14

> PIDTYPE_PID only changes the identified process...
> ...systems running realtime processes usually must have SMT disabled; you cannot make any response-time guarantees when the CPU has to compete with a sibling for the hardware. Core scheduling can ensure that realtime processes get a core to themselves while allowing the rest of the system to use SMT.

Is this control at the process level, or can threads within a process be assigned unique cookies? From the realtime perspective, it's common to have a realtime thread that offloads I/O to a non-realtime I/O thread within the same process (e.g., for data logging). One might want to ensure that the realtime thread does not experience interference from SMT, but not care about the non-realtime thread.

Thread or Process?

Posted Jul 7, 2021 10:17 UTC (Wed) by immibis (subscriber, #105511) [Link]

> The type argument controls how widely spread this assignment is; PIDTYPE_PID only changes the identified process, for example, while PIDTYPE_TGID assigns the cookie to the entire thread group. The cookie argument must be NULL.

Note that what the kernel calls a "process" or "task" is what us user-space plebs would call a "thread", and what they call a "thread group" is what we would call a "process".