Intégration Scheduler ↔ Resource Governor

Responsabilité

Documenter l'intégration architecturale entre le scheduler de tâches et le Resource Governor, incluant les frontières de responsabilités, le cycle de vie des réservations et le comportement en cas de pause.

Frontières de responsabilités

Scheduler

Ordonnancement FIFO
Exécution des callbacks
Gestion des états de tâche
Sélection de la première tâche admissible

Resource Governor

Arbitrage des budgets (RAM, GPU, CPU, IO)
Calcul des lots adaptatifs
Réservations opaques
Historique de métriques

Cycle d'exécution

1. Task → Estimate (estimation des ressources)
2. Scheduler → Governor → decide() (décision d'admission)
3. Governor → Reservation (réservation opaque)
4. Scheduler → Worker (exécution)
5. Worker → Governor → record_batch() (métriques)
6. Governor → release() (libération)

Admission

Réponses du gouverneur

ADMIT : la tâche peut démarrer
WAIT : la tâche doit attendre (pas de ressources)
REDUCE_BATCH : réduire la taille du lot
REJECT : rejeter la tâche

Comportement en cas de WAIT

Le scheduler saute la tâche en tête de file
Il évalue la tâche suivante
Pas de blocage de la file
Si aucune tâche n'est admissible mais qu'un WAIT PENDING subsiste, le worker effectue une attente temporisée d'au plus 500 ms, puis rescane normalement la file avec de nouveaux snapshots. Tout signal explicite le réveille plus tôt.
Cette attente appartient au worker existant : aucun thread de monitoring, nouveau scheduler ou nouveau sous-système n'est créé.

Gestion des pauses

Comportement actuel

Une tâche en pause conserve sa réservation
Évite de perdre son contrat au profit d'un autre travail
Permet la reprise avec le même lot

Règle

La réservation est conservée pendant la pause
La libération n'a lieu qu'à la fin de l'exécution

Séquences adaptatives

Mécanisme

lardon3d_task_sequence_break() permet de libérer la réservation courante
Capturer un nouvel instantané de ressources
Obtenir un contrat actualisé
Reprendre le callback en conservant la progression
L'attente d'admission à cette frontière conserve son polling existant de 50 ms ; elle est distincte des 500 ms de réévaluation d'une tâche initialement PENDING.

Avantages

Adaptation dynamique des lots en cours d'exécution
Réponse aux changements de ressources
Optimisation de l'utilisation mémoire

Invariants

Aucune tâche ne passe de PENDING à RUNNING sans réservation active
Le scheduler ne prend jamais de décision sur les ressources
La libération des réservations s'effectue exactement une fois par cycle/séquence
Les atomicités sont garanties sous mutex

Limites actuelles

Worker unique (pas de pools multiples)
Pas de DAG de dépendances
Pas de priorités
Pas de notification automatique de libération externe

3 KiB Raw Blame History