J'ai un système Linux où nous avons utilisé des cgroups pour créer deux cpusets cpu_exclusive, A et B, et où nous avons migré tous les threads utilisateur et tous les threads du noyau non liés vers un cgroup attaché à cpuset A. Les choses qui s'exécutent dans cpuset A ont différentes politiques de programmation. et des priorités variables, et il y a beaucoup plus de threads en cours d'exécution dans cpuset A que de cœurs dans cpuset A.
Il existe également un petit nombre de processus très actifs attachés à cpuset B, où le nombre total de threads utilisateur à travers ces processus n'est jamais supérieur au nombre de cœurs exclusivement disponibles dans cpuset B. Le but est de protéger ces tâches importantes exécutées dans cpuset B d'une autre activité sur la machine et pour minimiser la latence de traitement.
Dans une telle configuration, la politique / priorité de planification des threads utilisateur s'exécutant dans cpuset B a-t-elle un effet observable? Autrement dit: la modification de la stratégie de planification des threads du cpuset B de SCHED_OTHER par défaut à SCHED_FIFO ou SCHED_RR aurait-elle des conséquences, bonnes ou mauvaises?
Il semble que la réponse devrait être «non», car le planificateur devrait être en mesure d'attribuer à chaque thread s'exécutant dans cpuset B son propre noyau dédié, il n'y aurait donc rien à prioriser ou à planifier, et donc la politique et la priorité relative du B les threads cpuset n'auraient pas d'importance. D'un autre côté, il y a les threads du noyau liés et les aspects «domaine du planificateur» à se soucier, et probablement d'autres choses que je n'ai pas prises en compte.
Les politiques et priorités de planification des threads s'exécutant dans un cpuset exclusif surapprovisionné ont-elles un sens pratique?