Chris Siebenmann revient sur la façon dont la charge moyenne Unix, simple à l'époque de 3BSD et des machines à un seul processeur, s'est heurtée à trois questions de conception avec l'arrivée du multiprocesseur et des threads.

Première question : sur une machine à quatre CPU avec deux processus actifs en permanence, la charge moyenne vaut-elle 2 ou 0,5 ? Les Unix modernes comptent les processus prêts globalement, donc 2, quel que soit le nombre de CPU. Irix normalisait au départ par la capacité, de sorte que le chiffre représentait à peu près le même degré de charge sur toutes les machines. Cette approche a perdu. Aujourd'hui, il faut connaître le nombre de CPU en plus de la charge moyenne pour juger d'une surcharge.

Deuxième question : le comptage des threads. Le noyau ne voit ni les green threads ni les threads utilisateur multiplexés sur moins d'objets noyau. Les premières implémentations ne comptaient donc que ce que le noyau connaissait, parfois seulement les processus et non les threads. Linux a fait des threads une forme de processus, donc ils sont pleinement visibles. Le problème persiste dans les environnements comme Go : la charge moyenne montre les threads OS actifs, pas le nombre de goroutines en attente.

Troisième question : que compter au-delà des processus prêts. La charge moyenne 3BSD d'origine incluait les processus en attente d'IO disque, et des Unix commerciaux comme celui de Sun ont repris ce choix, l'IO NFS comptant comme IO disque. L'enquête de Brendan Gregg en 2017 a montré que Linux excluait initialement l'attente IO mais l'a ajoutée très tôt. Les BSD varient sur ce point.