sched_ext : Planificateurs BPF dans Linux 6.12

sched_ext dans le noyau Linux 6.12 : Planificateurs dynamiques avec BPF

La sortie du noyau Linux 6.12 introduit la classe de planificateur sched_ext, permettant le remplacement dynamique de la logique de planification des tâches via des programmes BPF. Cela élimine le besoin de correctifs et de reconstructions du noyau lors d’expérimentations avec des algorithmes. Les politiques sont chargées depuis l’espace utilisateur, le noyau assurant la sécurité grâce à un mécanisme de repli vers SCHED_NORMAL en cas d’échec.

La classe sched_ext divise les responsabilités : le noyau gère les files d’attente de dispatch (DSQ), la migration des tâches et la gestion d’état, tandis que la politique BPF décide de la classification, du rang et du quantum de temps. Au réveil d’une tâche, le hook enqueue() est invoqué ; lors du dispatch par le noyau, dispatch() est appelé.

Cycle de vie des tâches dans sched_ext

Une tâche se réveille via try_to_wake_up(), et la politique analyse ses caractéristiques : motifs de réveil, utilisation CPU/E-S, cgroup, et présence de politiques RT (SCHED_FIFO, SCHED_RR). La politique place la tâche dans une file globale ou locale, en utilisant le temps virtuel pour la priorisation.

Dans dispatch(), la tâche est défilée et remise au noyau via scx_bpf_dispatch() avec un quantum de temps en nanosecondes. La migration est déclenchée par scx_bpf_kick_cpu() pour l’équilibrage de charge ou la localité de cache.

Les files DSQ fonctionnent en mode FIFO ou priorité selon la méthode d’insertion :

• scx_bpf_dispatch() — sémantique FIFO.
• scx_bpf_dispatch_vtime() — ordonnancement par vtime.

Le rang (score) interne de la politique n’affecte pas les priorités du noyau (nice, prio).

Exemple : scx_horoscope comme démonstration des capacités

Le projet scx_horoscope utilise des données astrologiques pour ajuster les quanta de temps, illustrant le modèle sched_ext. Toutes les 60 secondes, il calcule les positions des planètes, rétrogrades et phases lunaires pour générer des coefficients.

Classification des tâches par :

• Politiques RT.
• Motifs de réveil.
• Utilisation CPU/E-S.
• cgroup.

Le quantum de base est ajusté par des multiplicateurs : signes du zodiaque boostent ou réduisent les quanta pour les types de tâches, rétrogrades imposent une pénalité de 50 %, et pleines lunes accordent des bonus aux tâches interactives. Les quanta sont bornés par min_slice_ns et max_slice_ns.

Ceci est un exemple éducatif : calculs réels avec fonctionnement stable, mais sans base scientifique pour une utilisation en production.

Planificateurs pratiques sur sched_ext

L’écosystème scx inclut des politiques orientées production :

• scx_lavd (Deadline Virtuel Conscient de la Latence) : deadlines virtuelles basées sur les motifs de réveil, réduisant les latences au 99e percentile de 15–30 % par rapport à CFS sur les postes de travail.
• scx_rusty : optimisation NUMA, migrations minimisées, et conscience des limites thermiques pour les serveurs.
• scx_flash : prédictions ML depuis l’espace utilisateur via mémoire partagée.

Les cycles de développement se sont réduits à quelques heures : compiler, charger, métriques, itérer — sans redémarrage nécessaire.

Outils pour le benchmarking

Évaluation via :

• /sys/kernel/sched_ext/ — métriques de dispatch et migration.
• bpftrace — traçage d’événements.
• perf sched — latences de commutation de contexte.
• cyclictest — latences de queue.

Accent sur les percentiles, pas les moyennes : les queues sont critiques pour la réactivité.

Cas d’usage :

• Serveurs de jeux : quanta garantis pour la logique de jeu, isolation des tâches en arrière-plan.
• Systèmes embarqués : groupement de tâches pour réduire la fréquence de commutation.
• Cloud : garanties de bande passante au-delà de cgroup.
• Audio/vidéo : réservation de cœurs, minimisation du jitter.

Limitations et développement

La surcharge des appels de dispatch augmente avec des taux de commutation élevés. Les erreurs logiques dégradent les performances sans déclencher de paniques. L’API évolue, et la fonctionnalité reste expérimentale.

Points clés :

• sched_ext dans 6.12 avec CONFIG_SCHED_CLASS_EXT.
• Politiques BPF pour prototypage rapide.
• Repli vers SCHED_NORMAL en cas d’échec.
• Accent sur les percentiles dans les benchmarks.
• Applications dans les scénarios critiques en latence et NUMA.

— Editorial Team