91 lines
3 KiB
Markdown
91 lines
3 KiB
Markdown
# 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
|
|
|
|
```text
|
|
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
|
|
|
|
1. Aucune tâche ne passe de PENDING à RUNNING sans réservation active
|
|
2. Le scheduler ne prend jamais de décision sur les ressources
|
|
3. La libération des réservations s'effectue exactement une fois par cycle/séquence
|
|
4. 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
|
|
|
|
## Statut : GATE G — PASS / FROZEN
|