Alla scala di Meta, pochi millisecondi di latenza in più sul percorso di serving degli ads si traducono in ranking meno accurati e ROI più basso per gli inserzionisti. La piattaforma gestisce in media più di 5 milioni di richieste al secondo al punto di ingresso, oltre 400 miliardi al giorno su tutte le superfici monetizzate. È in questo contesto che il team Ads e il team Linux Kernel hanno affrontato un problema concreto: l’upgrade del fleet al kernel 6.9 introduceva lo scheduler EEVDF (arrivato in 6.6), che causava una regressione di latenza e riduceva il numero di ads posizionati per risposta. Alcuni host erano rimasti bloccati sul vecchio kernel 6.4, creando debito tecnico e frammentazione operativa.
Uno scheduler che conosce il workload
La soluzione è stata sched_ext, il framework di scheduling estensibile basato su BPF entrato ufficialmente nel kernel v6.12. Gli scheduler general-purpose del kernel (CFS ed EEVDF) bilanciano i thread tra le CPU senza alcuna nozione del carico applicativo. sched_ext permette invece di scrivere la scheduling policy come programma BPF e di codificare direttamente la conoscenza del dominio: il lavoro che migliora la latenza p99 delle richieste viene schedulato per primo, tutto il resto passa in secondo piano.
La policy divide in modo “soft” le CPU in due pool, uno per i thread sul percorso critico delle richieste e uno per il lavoro meno sensibile alla latenza, con dimensioni regolate dinamicamente in base al carico. Tenere il lavoro correlato sulle stesse CPU migliora la località della cache di ultimo livello (L3) e riduce gli accessi costosi alla DRAM. Poiché la policy è un binario user-space che carica il programma BPF, per aggiornarla basta riavviare il processo dello scheduler, senza ricompilare o reinstallare il kernel.
Risultati e implicazioni
Il lancio iniziale, passando da kernel 6.4 con CFS a kernel 6.9 con sched_ext sul principale tipo di server per gli ads, ha prodotto un +1,1% sulla metrica weighted-ads-ranked, 3,28 megawatt di risparmio energetico sul fleet e una riduzione del 28% della latenza p99 sullo stadio di retrieval. Due aggiornamenti successivi della policy, interamente in user-space, hanno aggiunto un ulteriore 60% di riduzione della latenza p99 e un 18% in meno di errori di timeout sul percorso critico. Ogni iterazione è arrivata in giorni anziché mesi.
Il punto interessante per chi gestisce infrastrutture è il disaccoppiamento: le ottimizzazioni di scheduling non dipendono più dai rilasci del kernel, e idee come il placement cache-aware o il routing basato su ROI diventano iterazioni gestibili invece di progetti pluriennali. Essendo upstream in Linux v6.12, lo stesso meccanismo è ora disponibile a chiunque abbia workload che non si adattano al modello general-purpose.
- sched_ext ha trasformato un semplice sblocco all’upgrade del kernel in una piattaforma di ottimizzazione continua.
- Codificare la conoscenza del workload nello scheduler riduce la latenza di coda e, di riflesso, aumenta gli ads posizionati.
- Le policy vivono in user-space come programmi BPF: sperimentare costa molto meno che con una patch al kernel.
Fonte: Modernizing the Meta Ads Service With an Open-Source Kernel Scheduler — https://engineering.fb.com/2026/07/13/ml-applications/modernizing-the-meta-ads-service-with-an-open-source-kernel-scheduler/
Hai qualcosa da aggiungere? Unisciti alla discussione.