Lo que busca debe encontrarse dentro de este archivo virtual:
/sys/devices/system/cpu/isolated
y al revés en
/sys/devices/system/cpu/present // Thanks to John Zwinck
Desde drivers/base/cpu.c vemos que la fuente mostrada es la variable del 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);
y cpu_isolated_map es exactamente lo que establece kernel/sched/core.c en el arranque:
/* 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;
}
Pero como observaste, alguien podría haber modificado la afinidad de los procesos, incluidos los generados por demonios, cron , systemd y así. Si eso sucede, se generarán nuevos procesos que heredarán la máscara de afinidad modificada, no la establecida por isolcpus .
Así que lo anterior te dará isolcpus como lo solicitó, pero eso podría no ser útil.
Supongamos que descubres que isolcpus se ha emitido, pero no se ha "tomado", este comportamiento no deseado podría ser derivado por algún proceso que se dé cuenta de que está vinculado solo a CPU=0 , creyendo que está en modo monoprocesador por error e intentando ayudar a "arreglar las cosas" restableciendo la máscara de afinidad. Si ese fuera el caso, podría intentar aislar CPUS 0-5 en lugar de 1-6, y ver si esto funciona.
Una de las formas más fáciles de detectar si isolcpus está consultando proc para ver qué parámetros se pasaron al kernel en tiempo de ejecución.
Para eso, usarías:
$cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.8.0-1-amd64 root=/dev/sda1 ro isolcpus=2,3 quiet
Como puede ver, en este ejemplo particular isolcpus=2,3 se pasó como argumento al kernel en ejecución.
También puedes usar taskset apuntó a PID 1. Como PID 1 es el PID estándar para la primera tarea lanzada por el kernel, podemos tomar como una buena indicación que reflejará si tenemos isolcpus laboral. Como en:
$taskset -cp 1
pid 1's current affinity list: 0,1
Comparando con el lscpu comando en el mismo servidor:
$lscpu | grep CPU.s
CPU(s): 4
On-line CPU(s) list: 0-3
NUMA node0 CPU(s): 0-3
Como puede verse, lscpu muestra 4 CPU/núcleos, mientras que taskset solo muestra 0,1, por lo que muestra isolcpus está trabajando aquí.
Eche un vistazo a:¿Cómo garantizar la disponibilidad exclusiva de la CPU para un proceso en ejecución?
Puede verificar Cpus_allowed y Cpus_allowed_list para el proceso de shell actual para ver qué cpus se reservaron
cat /proc/$$/status|tail -6
por ejemplo
Cpus_allowed_list: 0-1, 3-5
significa que la cpu=2 fue reservada por isolcpus en un servidor de 6 CPU