J'essaie de comprendre ce qui se passe pendant la fonction load_balance.
Je vérifie la version 3.14 mais j'ai également jeté un coup d'œil à la version 4.3 car on m'a dit que le mécanisme avait été changé et un peu plus clair dans cette version.

Dans la v3.14 , l'appel provient de { {X0}}

Dans la v4.3 l'appel provient de detach_tasks

D'après ce que je vois, c'est la même fonction mais seulement avec un nom différent.

Cette fonction déplace les tâches d'une file d'attente à une autre selon le paramètre env->balance. Ce que je ne comprends pas, c'est quoi / comment la charge est calculée dans task_h_load.

Quelqu'un sait-il ce que représente le membre de charge et comment il est calculé dans la fonction task_h_load ?

17
boaz 23 déc. 2015 à 22:46

2 réponses

Meilleure réponse

CFS contient un arbre "d'entités de planification". Chaque entité de planification peut avoir sa propre arborescence, et ainsi de suite de manière récursive ... (Ceci est utile, par exemple, pour regrouper tous les processus d'un utilisateur spécifique dans une seule entité de planification; empêchant ainsi un utilisateur qui a de nombreuses tâches de consommer plus de temps cpu que les utilisateurs avec moins de processus)

Task_h_load - signifie " charge hiérarchique des tâches "

Puisqu'une tâche peut être imbriquée dans quelques arbres, calculer sa charge n'est pas si simple ...

static unsigned long task_h_load(struct task_struct *p){
    struct cfs_rq *cfs_rq = task_cfbs_rq(p);
    update_cfs_rq_h_load(cfs_rq);
    return div64_ul(p->se.avg.load_avg * cfs_rq->h_load,
                           cfs_rq_load_avg(cfs_rq) + 1);
}

Au début, cfs_rq pointe vers l'arbre immédiat dans lequel se trouve p. Si nous n'avions que deux arbres imbriqués, calculer la charge de p aurait été simple:

task_h_load = task_load_in_its_tree * (load_of_immediate_tree / load_of_containing_tree);

(tandis que immédiat_tree fait référence à l'arborescence qui contient la tâche, et Container_tree fait référence à l'arborescence qui contient l'arborescence qui contient la tâche.)

Mais ce n'est pas le cas. Notre arbre peut être un arbre imbriqué dans une entité de planification, qui n'est elle-même qu'une feuille dans un autre arbre.

Donc, la première chose que nous faisons est d'appeler update_cfs_rq_h_load(cfs_rq) qui calcule le facteur de charge hiérarchique pour cfs_rq et tous ses ascendants (ancêtres): cette fonction remonte la hiérarchie de l'arbre jusqu'à la racine, et de la racine à notre cfs_rq tout en calculant le facteur de charge hiérarchique pour chaque arbre de la hiérarchie.

Le calcul se fait de la même manière:

cfs_rq_h_load = cfs_rq_load_in_its_tree * (load_of_immediate_tree / load_of_containing_tree)

Donc, finalement, nous avons la charge fractionnaire de cfs_rq et tout ce que nous avons à faire est de calculer la charge h en utilisant la même formule.

task_h_load = task_load_in_its_tree * (load_of_immediate_tree / load_of_containing_tree)

8
Noamiko 3 janv. 2016 à 01:42

L'équilibrage de charge est appelé si SMP est configuré.Linux utilise Completely Fair Scheduler (CFS) pour planifier chaque tâche afin que chacune obtienne une part «équitable» du temps processeur. CFS utilise le concept de arbre rouge-noir.

enter image description here

Le planificateur enregistre l'heure actuelle à laquelle une tâche entre dans la file d'attente d'exécution. Pendant que le processus attend le temps du processeur, sa valeur «d'attente» est incrémentée d'un montant dérivé du nombre total de tâches actuellement dans la file d'attente d'exécution et de la priorité du processus. Lorsque le processeur exécute cette tâche, cette valeur «d'attente» est décrémentée. Si cette valeur tombe en dessous d'une certaine valeur, le planificateur anticipera la tâche et l'autre tâche se rapprochera du processeur pour s'exécuter. CFS essaie toujours de garder la situation idéale en gardant zéro la valeur «d'attente».

Il existe deux fonctions sous linux load_balance et select_task_rq_fair() qui effectuent la tâche d'équilibrage de la charge.

En un mot, le mécanisme d'équilibrage de charge CFS décharge le processeur occupé vers un processeur moins occupé ou idéal.

task_h_load est utilisé pour calculer le poids de la tâche.

Ce que je ne comprends pas, c'est quoi / comment la charge est calculée dans task_h_load. comment il est calculé dans la fonction task_h_load?

Ce facteur de poids dépend de la belle valeur du processus.

weighting factor = weight of process with nice value 0 / weight of current task;

Où «poids» équivaut approximativement à 1024 * (1.25) ^ (- sympa)

Par exemple: le poids est de 820 pour une belle valeur 1 le poids est de 1277 pour une belle valeur -1

task_h_load
Pour plus de méthodes et de principes de base d'équilibrage de charge, reportez-vous au noyau commentaire task_h_load utiliser update_cfs_rq_h_load pour calculer la charge hiérarchique de la file d'attente d'exécution pour une planification à temps équitable et qui utilisent cfs_rq_load_avg renvoyant la charge moyenne de runqueue load_avg.

Le temps d'exécution virtuel est le temps pondéré qu'une tâche a exécuté sur le processeur. CFS essaie toujours de garder ceci Rouge-noir arbre en équilibre.

enter image description here

& lt; - valeur plus petite ----------- valeur vruntime -------- valeur plus grande - & gt;

Chaque tâche exécutable est placée dans un arbre rouge noir auto-équilibré basé sur vruntime. Si la tâche est prête à être exécutée (signifie que la tâche n'attend aucune ressource), elle est placée dans l'arborescence. Si la tâche attend une ressource (c'est-à-dire en attente d'E / S), elle est supprimée. Les tâches qui ont moins de temps de traitement (c'est-à-dire plus petit vruntime) sont vers le côté gauche de l'arborescence et les tâches ayant plus de temps de traitement sont du côté droit de l'arbre.

Le nœud de gauche a la plus petite valeur de clé (pour CFS, c'est la tâche avec la priorité la plus élevée). L'arbre noir rouge à équilibrage automatique nécessite une opération O (lgN) pour naviguer vers le nœud gauche. Le planificateur met en cache cette valeur dans rb_leftmost. En récupérant uniquement cette valeur, le planificateur détermine la tâche à exécuter ensuite

Cet équilibre de charge est utilisé pour les tâches non réelles uniquement en temps réel des opérations push-pull de tâches sont utilisées, développées par Steven Rostedt et Gregory Haskins

Une autre chose à propos de CFS est également utile dans la planification de groupe équitable. Considérez sous la figure

enter image description here

move_task est essayez simplement de déplacer la charge pondérée par déséquilibre (c'est-à-dire après avoir calculé le facteur de charge comme indiqué ci-dessus) des occupations à this_rq. Il essaie d'égaler l'équilibre de charge des deux files d'attente d'exécution afin que les deux puissent épargner du temps processeur "équitable".

detach_task détache la tâche pour la migration spécifiée dans le pointeur env du noyau Linux.

detach_one_task essaie de retirer exactement une tâche de env- & gt; src_rq.

detach_tasks() essaie de se détacher jusqu'à charge pondérée de déséquilibre de busiest_rq. Et il renvoie le nombre de tâches détachées ou bien zéro si le détachement échoue.

Pour attacher cette tâche détachée au nouveau rq (file d'attente d'exécution), attach_task, attach_one_task,attach_tasks est utilisé en fonction de la situation.

Une nouvelle vérification d'avertissement lockdep_assert_held() est introduite dans detach_tasks qui n'était pas présent dans move_tasks

Sur les multiprocesseurs, il n'est pas facile de déplacer la tâche si facilement donc les cfs effectuent un équilibrage de charge spécifique au domaine comme ci-dessous: entrez la description de l'image ici

Pour que tout cela comprenne, j'aimerais que vous passiez par la référence suivante

  1. Métrique de suivi de charge par entité pour l'équilibrage de charge

  2. facteur de pondération

  3. Open-suse

  4. Robert-love Chapitre 3

  5. Programmation du processeur

J'ai spécialement lu toute cette documentation pour répondre à votre question. J'espère que cela ne vous dérange pas de commenter si quelque chose manque.

14
Punit Vara 3 janv. 2016 à 00:56