Chris Siebenmann repasa cómo el load average de Unix, simple en la época de 3BSD con máquinas de una sola CPU, se topó con tres cuestiones de diseño al llegar los sistemas multiprocesador y los hilos.

La primera cuestión: en una máquina con cuatro CPU y dos procesos siempre activos, ¿el load average es 2 o 0,5? Los Unix modernos cuentan los procesos ejecutables de forma global, así que la respuesta es 2, sin importar el número de CPU. Irix normalizaba inicialmente según la capacidad, de modo que el número representaba más o menos el mismo grado de carga en cualquier máquina. Esa opción no prosperó. Hoy hace falta conocer el número de CPU además del load average para juzgar si un sistema está sobrecargado.

La segunda cuestión es el recuento de hilos. El núcleo no puede ver los green threads ni los hilos de usuario multiplexados sobre menos objetos del núcleo. Las primeras implementaciones contaban solo lo que el núcleo conocía, a veces solo procesos y no hilos. Linux convirtió los hilos en una forma de proceso, por lo que son plenamente visibles. El problema persiste en entornos como Go: el load average muestra los hilos del sistema operativo activos, no el número de goroutines en espera.

La tercera cuestión es qué se cuenta más allá de los procesos ejecutables. El load average original de 3BSD incluía los procesos a la espera de E/S de disco, y Unix comerciales como el de Sun copiaron eso, contando la E/S de NFS como E/S de disco. La investigación de Brendan Gregg de 2017 mostró que Linux inicialmente excluía la espera de E/S pero la incorporó muy pronto. Los BSD varían en este punto.