Les architectures NUMA, où chaque processeur a un contrôleur
mémoire dédié, nécessitent une révision de l'ordonnanceur.
En effet, l'ordonnanceur doit tenir compte de la topologie
du CPU pour placer un processus sur le cœur le plus proche
de sa mémoire. L'ordonnanceur actuel est trop naïf pour ces
architectures, ce qui provoque des pertes de performances.
Le problème est justement qu'il ne faut que ce soit uniquement l'ordonnanceur qui gère ça. Si les données sont bien réparties en mémoire, il arrivera peut-etre à répartir les processus près de leurs données tout en équilibrant bien la charge parmi les processeurs. Mais dans la plupart des cas, mettre les processus près de leurs données va imposer un déséquilibre de charge de calcul.
Et on se pose alors la question de migrer certaines données vers un autre noeud NUMA. En gros il faut répartir les données et les calcul en même temps, pas l'un puis l'autre.
Au final, il faut que l'ordonnanceur et la gestion mémoire se mettent d'accord sur une de ces stratégies :
1) est-ce qu'on migre les processus près des données (pas très cher, mais peut déséquilibrer la charge de calcul)
2) est-ce qu'on migre les données près des processus (cher, équilibre mieux la charge de calcul)
3) ne rien faire, équilibrer la charge et avoir éventuellement des processus qui utilise des données loin d'eux, et donc plus lentement.
Comparer ces trois approches est très difficile car ça impose de connaître les schémas d'accès mémoire des processus pour évaluer les différents surcoûts ci-dessus.
# ordonnancement NUMA
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 5.
Le problème est justement qu'il ne faut que ce soit uniquement l'ordonnanceur qui gère ça. Si les données sont bien réparties en mémoire, il arrivera peut-etre à répartir les processus près de leurs données tout en équilibrant bien la charge parmi les processeurs. Mais dans la plupart des cas, mettre les processus près de leurs données va imposer un déséquilibre de charge de calcul.
Et on se pose alors la question de migrer certaines données vers un autre noeud NUMA. En gros il faut répartir les données et les calcul en même temps, pas l'un puis l'autre.
Au final, il faut que l'ordonnanceur et la gestion mémoire se mettent d'accord sur une de ces stratégies :
1) est-ce qu'on migre les processus près des données (pas très cher, mais peut déséquilibrer la charge de calcul)
2) est-ce qu'on migre les données près des processus (cher, équilibre mieux la charge de calcul)
3) ne rien faire, équilibrer la charge et avoir éventuellement des processus qui utilise des données loin d'eux, et donc plus lentement.
Comparer ces trois approches est très difficile car ça impose de connaître les schémas d'accès mémoire des processus pour évaluer les différents surcoûts ci-dessus.