O que você procura deve ser encontrado dentro
/sys/devices/system/cpu/isolated
e o inverso em
/sys/devices/system/cpu/present // Thanks to John Swinck
A partir de drivers/base/cpu.c
, vemos que a fonte exibida é a variável do kernel cpu_isolated_map
:
static ssize_t print_cpus_isolated(struct device *dev,
n = scnprintf(buf, len, "%*pbl\n", cpumask_pr_args(cpu_isolated_map));
...
static DEVICE_ATTR(isolated, 0444, print_cpus_isolated, NULL);
e cpu_isolated_map
é exatamente o que é definido por kernel/sched/core.c
no boot:
/* Setup the mask of cpus configured for isolated domains */
static int __init isolated_cpu_setup(char *str)
{
int ret;
alloc_bootmem_cpumask_var(&cpu_isolated_map);
ret = cpulist_parse(str, cpu_isolated_map);
if (ret) {
pr_err("sched: Error, all isolcpus= values must be between 0 and %d\n", nr_cpu_ids);
return 0;
}
return 1;
}
Mas, como você observou, alguém poderia ter modificado a afinidade dos processos, incluindo os gerados pelo daemon, cron
, systemd
e assim por diante. Se isso acontecer, novos processos serão gerados herdando a máscara de afinidade modificada, não a definida por isolcpus
.
Então, o que foi mencionado acima lhe dará isolcpus
conforme solicitado, mas isso ainda pode não ser útil.
Supondo que você descubra que isolcpus
foi emitido, mas não "aceitou", esse comportamento indesejado poderia ser derivado por algum processo, percebendo que está vinculado apenas a CPU=0
, Acreditando que está no modo monoprocessador por engano, e tentando ajudar "acertar as coisas", redefinindo a máscara de afinidade. Se fosse esse o caso, você poderia tentar isolar o CPUS 0-5 em vez do 1-6, e ver se isso funciona.