• Auf der Skala von Meta, Selbst eine Latenzverschlechterung um einige Millisekunden kann erhebliche negative Auswirkungen auf die Anzeigenleistung haben.
• Als ein Linux-Kernel-Upgrade drohte, die Latenz in der gesamten Adserving-Flotte von Meta zu verringern, Wir wandten uns an sched_ext – der Upstream, BPF-basiertes erweiterbares Planungsframework – um eine Planungsrichtlinie zu erstellen, die auf die Arbeitslast bei der Anzeigenbereitstellung zugeschnitten ist.
• Das Ergebnis: A 28% Reduzierung der Anzeigenabrufphase (99Perzentil) der Latenz, A 3.28 Megawatt (MW) Energieeinsparungen, und a 1.1% Erhöhung der Anzahl der angezeigten Anzeigen, Dies beweist, dass arbeitslastspezifische Planungsoptimierung den Geschäftswert direkt steigern kann.

Die Adserving-Flotte von Meta verarbeitet durchschnittlich mehr als 5 Millionen Anfragen pro Sekunde am Einstiegspunkt der Lieferplattform, was gleichbedeutend mit vorbei ist 400 Milliarden pro Tag auf allen monetarisierten Oberflächen¹. Jede Millisekunde, die bei der p99-Latenz eingespart wird, macht Anzeigen für die Menschen auf unseren Plattformen relevanter, Und bessere Übereinstimmungen bedeuten einen höheren ROI für Werbetreibende.

Dies stellt eine echte Chance dar, die Latenz durch arbeitslastspezifische Planung zu reduzieren. Aus diesem Grund haben unsere Ads- und Linux-Kernel-Teams zusammengearbeitet, um mithilfe von sched_ext eine Planungsrichtlinie zu erstellen, die auf die Arbeitslast bei der Anzeigenbereitstellung zugeschnitten ist, der Upstream, BPF-basiertes erweiterbares Planungsframework. Bisher haben wir die üblicherweise im Linux-Kernel integrierten Scheduler verwendet (CFS und EEVDF), die Threads auf CPUs verteilen, ohne die Arbeitslast zu kennen. Jedoch, Hier kennen wir den Zweck und die Bedeutung jedes Threads. Mit sched_ext können wir dieses Wissen direkt in den Scheduler kodieren. Zunächst sind Arbeiten zur Verbesserung der p99-Anfragelatenz geplant, alles andere tritt in den Hintergrund.

sched_ext bei Meta

Sched_ext ist ein Open-Source-BPF-basiertes Scheduler-Framework, das offiziell in Kernel v6.12 eingeführt wurde. Wir haben es in Zusammenarbeit mit den Autoren von Google entwickelt ghOSt, einen Scheduler zu entwerfen, der für die Upstream-Linux-Integration geeignet ist. Es wurde bereits in mehreren Diensten bei Meta eingesetzt und sorgt für eine deutliche Reduzierung der Planungslatenz.

Während wir unsere Flotte auf die neueste stabile Version von Linux aktualisieren (Kernel v6.9) Wir haben festgestellt, dass das Neue Frühestmöglicher virtueller Termin zuerst (EEADF) Scheduler eingeführt in Linux-Kernel v6.6 verursachte eine Latenzregression, die die Anzahl der als responsiv eingestuften Anzeigen verringerte. Infolge, Ein Teil der Anzeigenhosts war gezwungen, auf dem älteren v6.4-Kernel zu bleiben, Dies führt zu technischer Verschuldung und betrieblicher Fragmentierung.

Angesichts seiner bereits starken Leistung, sched_ext war ein großartiger Kandidat für die Bewältigung dieser Planungsregressionen.

Benutzerdefinierte Planung mit sched_ext

Mit Sched_ext können Scheduler-Entwickler ihre Präferenzen implementieren Planungspolitik als BPF-Programm. Wenn ein Host mit der Ausführung der Anzeigen-Workload beginnt, Es wird eine werbeoptimierte Richtlinie angewendet. Von diesem Punkt an, Der Kernel ruft den BPF-Scheduler über eine Reihe ereignisgesteuerter Rückrufe auf, um allgemeine Planungsereignisse zu verarbeiten, z:

• Thread-Wakeup: Wählen Sie eine CPU aus, wenn ein Thread ausführbar wird.
• Warteschlange: Platzieren Sie einen Thread in einer Ausführungswarteschlange.
• Schicken: Wählen Sie den nächsten Thread aus, wenn eine CPU inaktiv wird.
• Leerlaufübergänge: Reagieren Sie auf CPUs, die in den Leerlaufzustand wechseln oder ihn verlassen.

Politik auf hohem Niveau Verteilt CPUs sanft auf zwei Poolseine für Threads auf dem latenzkritischen Anforderungspfad und eine für weniger latenzempfindliche Arbeiten. Welcher Thread in welchen Pool gelangt, ist Teil des domänenspezifischen Wissens, das in der Richtlinie kodiert ist. Die Größe jedes Pools wird mithilfe lastbasierter Heuristik dynamisch angepasst. Dieser Ansatz tendiert dazu, verwandte Arbeiten im Laufe der Zeit auf denselben CPUs zu belassen, es zu verbessern Lokalität des Caches der letzten Ebene (L3). und Reduzierung des kostspieligen DRAM-Zugriffs.

Die Richtlinie ist als User-Space-Binärdatei verpackt, die das BPF-Programm lädt. Dieses Design beschleunigt das Experimentieren und die Leistungsoptimierung erheblich. Eine Änderung einführen, Wir können den Scheduler-Prozess einfach neu starten, um die alte Richtlinie zu entladen und die neue zu laden, ohne den Kernel neu zu erstellen oder zu installieren.

Der erste Start Es gab einen Übergang vom Kernel 6.4 mit dem CFS-Scheduler zum Kernel 6.9 mit sched_ext auf dem Servertyp mit der größten Anzeigenbereitstellung. Basierend auf dem Backtest-Experiment, Die Einführung bereitgestellt:

• +1.1% im gewichteten Anzeigenranking (Metrik für die Anzahl der angesehenen und eingestuften Anzeigen).
• 3.28 Megawatt von Energieeinsparungen in der gesamten Flotte.
• 28% Reduzierung der Service-P99-Latenz auf dem Anzeigenabrufpfad².

Verbundverbesserungen. Zwei aufeinanderfolgende Aktualisierungen der Scheduler-Richtlinien, werden als benutzerspezifische Änderungen bereitgestellt, verlängerte den Sieg:

• Zusätzlich 60% Reduzierung der Service-P99-Latenz.
• 18% Reduzierung von Timeout-Fehlern bei kritischen Pfaden.

Dies ist ein nicht trivialer Gewinn, der ohne Abhängigkeit von Kernel-Releases erzielt wird. Jede der oben genannten nachfolgenden Iterationen wurde in Tagen statt in Monaten ausgeliefert, da die Scheduler-Richtlinie als BPF-Programm im Benutzerbereich ausgeführt wird. Dieser Rhythmus hat sched_ext von einem „Kernel-Upgrade-Unblocker“ zu einer kontinuierlichen Optimierungsplattform für die Anzeigenbereitstellung gemacht.

Was als gezielte Reaktion auf ein sehr spezifisches betriebliches Problem begann, hat sich als viel strategischer und breiter anwendbar erwiesen, als wir ursprünglich erwartet hatten. sched_ext bietet Meta einige wichtige Vorteile:

Ein paralleler und entkoppelter Scheduler-Optimierungspfad. Die Upstream-Linux-Planung entwickelt sich natürlich im Laufe der Zeit weiter, manchmal in größeren Schritten (z.B. Übergang von CFS zu EEVDF), Dies kann für nachgeschaltete Verbraucher störend sein. sched_ext gibt Meta die Flexibilität, diese benutzerdefinierten Scheduler parallel zu dieser Entwicklung kontinuierlich zu verbessern. Wir pflegen und verfeinern unsere eigene BPF-basierte Planungslogik, die auf die individuellen Anforderungen unserer Produktionsarbeitslasten zugeschnitten ist, So bleiben unsere kritischen Dienste unabhängig davon, was vorgelagert geschieht, optimiert.

Unabhängige Bereitstellung und reduzierte Gemeinkosten. Planerverbesserungen werden als BPF-Programmaktualisierungen bereitgestellt, in Tagen statt in Monaten. Die daraus resultierende Reduzierung der Experimentierkosten ist transformativ. Ideen, die zuvor einen Kernel-Patch und eine monatelange Validierung erforderten – Lokale Cache-fähige Platzierung, ROI-basiertes Executor-Routing, NUMA-fähige Steuerung – werden zu überschaubaren Iterationen und nicht zu Großprojekten.

Ein gemeinsamer Branchenwert. sched_ext wurde in Linux v6.12 upstreamed, Daher steht der hier verwendete Meta-Mechanismus nun dem gesamten Linux-Ökosystem zur Verfügung. Jeder Bediener mit einer Arbeitsbelastung, die nicht dem allgemeinen Modell entspricht – Hyperscaler, Cloud-Anbieter, Team für eingebettete Systeme – kann arbeitslastspezifische Planungsrichtlinien bereitstellen, ohne den Kernel zu forken.

Mit sched_ext können wir bereits Möglichkeiten für weitere Verbesserungen der Anzeigenleistung identifizieren, indem wir der Anwendung eine detailliertere Kontrolle über das Verhalten des Planers geben. Zum Beispiel, Anzeigendienste verfügen über wichtigen Kontext zur relativen Wichtigkeit von Dienstanfragen und können dem Planer möglicherweise signalisieren, wenn ein Thread mit der Arbeit an einer wichtigen Anfrage beginnt. Wenn der Planer diese Mitteilung erhält, er oder sie kann entsprechende Schritte einleiten, wie zum Beispiel: B. Erhöhen Sie die Größe des Planungsabschnitts dieses Threads oder stellen Sie sicher, dass er immer ganz oben in der Warteschlange steht.

Besonderer Dank geht an Samuel Nair, Osama Arif, GP Musumeci, Praveen Alevoor, Ye Wang, und dem breiteren Ads Capacity Efficiency- und Kernel-Team für ihre Beiträge und Zusammenarbeit.

Ads Infra-Führungsteam: Uladsimir Paschkewitsch, Varna Puvvada, Prabhakar Goyal, Neeraj Agrawal, Nein, Yan, Liz Shepherd, Drew Lackman