Un estudio universitario de la Universidad de Illinois (UIUC) sobre los planificadores del kernel de Linux revela que la métrica correcta lo es casi todo a la hora de evaluar decisiones de planificación. Los autores partieron de la idea clásica de mantener los procesos en el mismo núcleo para conservar caliente la caché, y se preguntaron qué ocurre con el acceso a memoria compartida en máquinas multisocket. En un Xeon de doble socket, según dónde se coloque un hilo, un fallo de caché puede resolverse sin acciones de coherencia, forzando un write-back al L3 compartido dentro del socket, o requiriendo un costoso trasiego entre sockets a través del chipset, con la penalización asimétrica que eso implica.
Para responder a cuánto importa mantener los procesos multi-hilo dentro de un mismo dominio LLC, qué tan bien lo hacen los planificadores actuales y cómo mejorarlos, el equipo comparó el planificador estándar de Linux con LAVD, además de restringir manualmente hilos a un socket con numactl. El hallazgo más llamativo: el planificador estándar y LAVD rindieron de forma muy parecida, pero fijar los hilos a un único socket con numactl aceleró algunas cargas hasta 3 veces, porque el balanceador reparte hilos entre sockets aunque eso perjudique al programa. Aun así, la métrica habitual de fallos read-for-ownership en L3 no siempre explicó el speedup, dejando sin resolver dos misterios —el caso de mediawiki, que apenas mejoró pese a menos fallos, y perlbench, que mejoró muchísimo sin motivo claro— que los autores no lograron cerrar antes de la entrega.