Loading…
Modernizing the Meta Ads Service With an Open-Source Kernel Scheduler
Summary
Meta's ad serving fleet encountered latency regressions and technical debt after Linux kernel upgrades introduced the default EEVDF scheduler. To resolve these performance drops across billions of daily requests, the engineering team implemented sched_ext, an open-source, BPF-based scheduling framework integrated into Linux kernel v6.12. The custom scheduling policy uses domain knowledge to soft-partition CPUs dynamically into separate pools for latency-critical request threads and background work, enhancing L3 cache locality. Packaged as a user-space binary, the scheduler allows policy iterations and rollouts via process restarts without kernel rebuilds. The deployment achieved a 28% reduction in p99 ads retrieval latency, a 1.1% increase in ranked ads, and 3.28 megawatts in fleet-wide power savings.
Takeaways
- Custom sched_ext policies soft-partition CPUs dynamically to separate latency-critical requests from less sensitive work, improving L3 cache locality and minimizing DRAM access.
- Packaging the BPF scheduler within a user-space binary enables policy updates and rollouts via process restarts in days rather than requiring multi-month kernel upgrade cycles.
- Replacing general-purpose kernel scheduling with an ads-optimized sched_ext policy reduced ads retrieval p99 latency by 28% and saved 3.28 megawatts of power across Meta's fleet.
Related reading
Meta ·
GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model
Meta's Generative Ads Recommendation Model (GEM) trains across thousands of GPUs using a hybrid architecture featuring trillions of sparse embedding parameters and billions of dense parameters. Standard training infrastructure built for large language models struggles with recommendation-specific workloads characterized by jagged user activity histories, asymmetric attention patterns, and numerical sensitivity. To overcome these bottlenecks, engineering teams introduced custom kernels like Jagged Flash Attention and Generalized Dot-Product Attention alongside MXFP8 mixed-precision execution. Pairing these kernel optimizations with topology-aware 5D parallelism doubled end-to-end training efficiency to 20–25% Model FLOPs Utilization while scaling total training FLOPs fourfold over twelve months.
Grab ·
How Grab built a scalable, high-performance ad server
Grab transitioned from an off-the-shelf MVP to an in-house ad serving system to accommodate business scale, hyperlocal requirements, and machine learning personalization. The architecture orchestrates core microservices and data pipelines across sequential steps: targeting, capping, pacing, scoring, ranking, pricing, and tracking. ElasticSearch serves as the targeting ads repository, while ScyllaDB acts as the high-throughput stats store fed by Kafka streams and data pipelines. The system operates on key engineering principles including parallelization and tuned latency limits, graceful fallbacks for slow dependency calls, and a unified server serving all ad types across the superapp.
Anthony McCallumGrab ·
Understanding Supply & Demand in Ride-hailing Through the Lens of Data
Grab measures ride-hailing supply and demand across space and time to resolve geo-temporal allocation mismatches between moving drivers and ride-seeking passengers. The analytics pipeline defines supply as idle online drivers and demand as passengers checking fares within brief time slots, aggregating locations into geohashes. Each driver is mapped across neighbouring demand units and inversely weighted by straight-line distance, which yields the effective supply, supply-demand ratio, and supply-demand difference for each geographic polygon. Grab uses these aggregated metrics to identify marketplace imbalances, deploying driver heatmaps to shift excess supply and passenger travel trend widgets to defer time-insensitive ride requests.
Aayush GargGithub ·
From latency to instant: Modernizing GitHub Issues navigation performance
GitHub Issues addressed navigation latency by shifting workloads to the client using a local-first, stale-while-revalidate architecture. To evaluate perceived delays, the team tracked user transitions through Highest Priority Content thresholds, aiming for instant rendering in under 200 milliseconds. The core implementation added a persistent client-side cache using IndexedDB, paired with a synchronous in-memory tier to serve hot issue payloads without asynchronous overhead. A selective preheating mechanism resolves missing cache entries for high-intent links without overburdening backend capacity with redundant requests. Following broad rollout, the proportion of instant React soft navigations increased from 4% to approximately 22%, yielding an overall cache-hit ratio of around 33%.
Natalie Guevara