• Chez Meta’échelle, même quelques millisecondes de dégradation de la latence peuvent avoir un impact négatif significatif sur les performances des annonces.
• Lorsqu'une mise à niveau du noyau Linux menaçait de réduire la latence sur Meta’flotte de diffusion d'annonces, nous nous sommes tournés vers sched_ext – l'amont, Cadre de planification extensible basé sur BPF – pour créer une politique de planification adaptée à la charge de travail de diffusion d'annonces.
• Le résultat: un 28% réduction de la phase de récupération des publicités (99ème centile) de latence, un 3.28 mégawatt (MW) économies d'énergie, et un 1.1% augmentation du nombre d'annonces affichées, prouver que l'optimisation de la planification spécifique à la charge de travail peut directement générer de la valeur commerciale.

Méta’Le parc de diffusion d'annonces traite en moyenne plus de 5 millions de requêtes par seconde au point d'entrée de la plateforme de livraison, ce qui équivaut à plus 400 milliards par jour sur toutes les surfaces monétisées¹. Chaque milliseconde réduite par rapport à la latence p99 rend les publicités plus pertinentes pour les utilisateurs de nos plateformes., et de meilleures correspondances signifient un meilleur retour sur investissement pour les annonceurs.

Cela représente une réelle opportunité de réduire la latence grâce à une planification spécifique à la charge de travail.. Que’C'est pourquoi nos équipes Ads et Linux Kernel ont travaillé ensemble pour créer une politique de planification adaptée à la charge de travail de diffusion d'annonces à l'aide de sched_ext., l'amont, Cadre de planification extensible basé sur BPF. Jusqu'à présent, nous avons utilisé les planificateurs généralement intégrés au noyau Linux. (CFS et EEVDF), qui distribuent les threads entre les processeurs sans connaître la charge de travail. Cependant, ici nous connaissons le but et l'importance de chaque fil. Avec sched_ext nous pouvons encoder ces connaissances directement dans le planificateur. Des travaux visant à améliorer la latence des requêtes p99 sont prévus en premier, tout le reste passe au second plan.

sched_ext chez Meta

Sched_ext est un framework de planification open source basé sur BPF officiellement introduit dans le noyau v6.12. Nous l'avons développé en collaboration avec les auteurs de Google ghOSt pour concevoir un planificateur adapté à l'intégration Linux en amont. Il a déjà été utilisé dans plusieurs services chez Meta et permet une réduction significative de la latence de planification.

Alors que nous mettons à niveau notre flotte vers la dernière version stable de Linux (Noyau v6.9) nous avons observé que le nouveau Premier rendez-vous virtuel éligible en premier (FEADER) Planificateur introduit dans Noyau Linux v6.6 provoqué une régression de la latence qui a réduit le nombre d'annonces classées comme réactives. Par conséquent, une partie des hôtes publicitaires a été obligée de rester sur l'ancien noyau v6.4, entraînant une dette technique et une fragmentation opérationnelle.

Compte tenu de ses performances déjà solides, sched_ext était un excellent candidat pour gérer ces régressions de planification.

Planification personnalisée avec sched_ext

Sched_ext permet aux développeurs de planificateurs d'implémenter leurs préférences Politique de planification en tant que programme BPF. Lorsqu'un hôte commence à exécuter la charge de travail publicitaire, une règle optimisée pour les annonces est appliquée. A partir de ce moment, le noyau appelle le planificateur BPF via une série de rappels basés sur des événements pour gérer les événements de planification courants tels que:

• Réveil du fil: Sélectionnez un processeur lorsqu'un thread devient exécutable.
• File d'attente: Placer un thread dans une file d'attente d'exécution.
• Envoyer: Sélectionnez le thread suivant lorsqu'un processeur devient inactif.
• Transitions inactives: Répondre aux CPU entrant et sortant des états inactifs.

La politique à un niveau élevé Distribue doucement les processeurs en deux poolsun pour les threads sur le chemin de requête critique en termes de latence et un pour le travail moins sensible à la latence. Quel fil va dans quel pool fait partie des connaissances spécifiques au domaine codées dans la politique. La taille de chaque pool est ajustée dynamiquement à l'aide d'heuristiques basées sur la charge. Cette approche tend à conserver les travaux associés sur les mêmes processeurs au fil du temps., l'améliorer Localité du cache de dernier niveau (L3). et réduire les accès coûteux à la DRAM.

La stratégie est présentée sous forme de binaire en espace utilisateur qui charge le programme BPF.. Cette conception accélère considérablement l'expérimentation et l'optimisation des performances. Pour déployer un changement, nous pouvons simplement redémarrer le processus du planificateur pour décharger l'ancienne politique et charger la nouvelle sans reconstruire ni installer le noyau.

Le premier départ Il y a eu une transition depuis le noyau 6.4 avec le planificateur CFS au noyau 6.9 avec sched_ext sur le type de serveur avec la plus grande diffusion d'annonces. Basé sur l'expérience de backtest, l'introduction fournie:

• +1.1% dans le classement pondéré des annonces (Mesure du nombre d'annonces vues et classées).
• 3.28 mégawatts d’économies d’énergie sur l’ensemble de la flotte.
• 28% réduction de la latence du service P99 sur le chemin de récupération des annonces².

Améliorations composées. Deux mises à jour ultérieures de la stratégie du planificateur, livré sous forme de modifications réservées aux utilisateurs, prolongé la victoire:

• Supplémentaire 60% réduction de la latence du service p99.
• 18% réduction des erreurs d'expiration du chemin critique.

Il s'agit d'un gain non trivial fourni sans dépendance aux versions du noyau. Chacune des itérations suivantes ci-dessus est expédiée en jours au lieu de mois, car la stratégie du planificateur s'exécute comme un programme BPF dans l'espace utilisateur.. Ce rythme a transformé sched_ext d'un « débloqueur de mise à niveau du noyau » à une plate-forme d'optimisation continue pour la diffusion d'annonces..

Ce qui a commencé comme une réponse ciblée à un problème opérationnel très spécifique s’est avéré beaucoup plus stratégique et largement applicable que ce à quoi nous nous attendions initialement.. sched_ext offre à Meta des avantages importants:

Un chemin d’optimisation du planificateur parallèle et découplé. La planification Linux en amont évolue naturellement avec le temps, parfois par tranches plus importantes (par exemple. transition du CFS vers l'EEVDF), ce qui peut perturber les consommateurs en aval. sched_ext donne à Meta la flexibilité nécessaire pour améliorer continuellement ces planificateurs personnalisés en parallèle de ce développement. Nous maintenons et affinons notre propre logique de planification basée sur BPF, adaptée aux besoins uniques de nos charges de travail de production., afin que nos services critiques restent optimisés quoi qu'il arrive en amont.

Déploiement indépendant et frais généraux réduits. Les améliorations du planificateur sont apportées au fur et à mesure des mises à jour du programme BPF, en jours plutôt qu'en mois. La réduction des coûts d’expérimentation qui en résulte est transformatrice. Des idées qui nécessitaient auparavant un correctif du noyau et des mois de validation – placement local prenant en compte le cache, Routage de l'exécuteur basé sur le retour sur investissement, Contrôle compatible NUMA – devenir des itérations gérables plutôt que des projets à grande échelle.

Une valeur industrielle partagée. sched_ext a été mis en amont dans Linux v6.12, le mécanisme Meta utilisé ici est donc désormais disponible pour l'ensemble de l'écosystème Linux. Tout opérateur ayant une charge de travail qui ne’ne correspond pas au modèle général – hyperscaler, fournisseur de cloud, équipe systèmes embarqués – peut fournir des politiques de planification spécifiques à la charge de travail sans bifurquer le noyau.

sched_ext nous permet déjà d'identifier les opportunités d'amélioration supplémentaire des performances des annonces en donnant à l'application un contrôle plus granulaire sur le planificateur.’le comportement. Par exemple, les services publicitaires ont un contexte important sur l'importance relative des demandes de service et peuvent être en mesure de signaler au planificateur lorsqu'un thread commence à travailler sur une demande importante. Lorsque le planificateur reçoit cet avis, il ou elle peut prendre les mesures appropriées, tel que: B. augmenter la taille de ce fil’s section de planification ou en veillant à ce qu'il soit toujours en haut de la file d'attente.

Des remerciements particuliers vont à Samuel Naïr, Oussama Arif, GP Musumeci, Praveen Alevoor, Ye Wang, et l'ensemble de l'équipe Ads Capacity Efficiency et Kernel pour leurs contributions et leur collaboration..

Équipe de direction Ads Infra: Ouladzimir Pashkevitch, Varna Pouvvada, Prabhakar Goyal, Neeraj Agrawal, Non Yan, Liz Berger, Drew Lackman