Re: a question about SCHED_FIFO on multicores
On Tue, 22 May 2012, Matej Kosik wrote:
> This "almost-monopolizing" should be safe as long as I run my process on
> a CPU where no other process runs.
It is easy for user processes. It is not easy for kernel threads.
> Affinity of some processes cannot be modified. E.g.:
>
> [migrate/0]
> [migrate/1]
> ...
>
> but these processes all run as SCHED_FIFO with priority 99 (maximum).
Those are kernel threads. You can, as root, change their scheduling
priority... but that may well cause priority inversion problems and thus a
livelock. It is deep into "you better really know what you're doing" land.
> This theory can be reproducibly disproved by:
> - booting Debian (without Xorg)
> - excluding CPU#0 from the affinity of all processes (for which this is
> possible)
Don't mess with CPU#0 if it is the BSP (bootstrap processor, aka "the core
the system boots from"). It is somewhat "special", and you cannot, e.g.,
offline it with impunity (at least not yet, someone was working on it). And
if you really want it to be free of contention, use hwloc to make sure you
got the entire core (and not just one of its hardware threads).
> (less than the priority of all other processes runnable on that core)
> After I run the above program, the text console will become non-responsive.
Well, two things come to mind: Make sure all new processes will be created
with their default affinity masking off that CPU. Also, check interrupt
affinity.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: