Skip to content

Gthulhu

Keep critical workloads fast when CPUs get busy

Gthulhu is a cloud-native runtime scheduling platform built with eBPF and Linux sched_ext. It protects latency- and throughput-sensitive Linux tasks inside Kubernetes workloads when CPU contention would otherwise slow them down.

Get Started View on GitHub

free5GC / 5G user plane

97.66% lower average latency

88.98 ms β†’ 2.079 ms average UE ping latency under CPU stress.

Maximum latency also fell from 130.95 ms β†’ 8.45 ms.

Read the published free5GC case study β†’

vLLM / GPU inference

~3.2Γ— decode throughput

~6.7 t/s β†’ ~21.3 t/s on tg128 under CPU pressure with Gthulhu + tiered scheduling policy.

Reproducible community benchmark currently under upstream vLLM blog review.

Review the benchmark and methodology β†’

cncf landscape ebpf landscape LFX Health Score

The problem Gthulhu solves

Kubernetes can place a workload on the right node and allocate the right resources. That still does not guarantee the workload's critical Linux threads will get CPU time when they need it.

Under contention, GPU feeder threads, EngineCore, packet-processing workers, IRQ-related work, or other latency-sensitive tasks can be delayed by background CPU load. The result is simple: allocated resources, but missed SLOs.

Gthulhu closes that execution gap.

1. Observe
Use eBPF to see which tasks are waiting, running, migrating, and competing for CPU.

2. Target
Resolve Kubernetes workload intent down to the Linux process or thread that actually matters.

3. Control
Use sched_ext to apply bounded runtime scheduling policy and protect critical execution paths.

DRA chooses what and where. Gthulhu controls how it actually runs.

Built for workload-aware runtime scheduling

  • Scheduling observability

    Pod-level scheduling metrics with eBPF, plus Prometheus and Grafana integration.

  • Fine-grained control

    Apply scheduling intent to specific workloads, processes, or non-leader worker threads with TID-aware matching.

  • Cloud-native operation

    Manager + per-node Decision Makers distribute scheduling intent across Kubernetes nodes.

  • SLO-oriented automation

    Feed scheduler signals into Prometheus, Grafana, and KEDA to support runtime-aware operations and scaling.

See how Gthulhu works

Where Gthulhu is going: Claim2Core

Today, Gthulhu can observe and control Linux task scheduling at runtime. The next step is to connect that control directly to Kubernetes' actual resource allocation.

Kueue / Workload API
        ↓
kube-scheduler / DRA
        ↓  ResourceClaim + topology
Gthulhu Runtime Plane
        ↓  Pod / cgroup / TGID / TID
sched_ext + eBPF
        ↓
Delivered workload SLO

The principle is simple:

  • ResourceSlice tells us what resources exist.
  • ResourceClaim.status.allocation tells us what the workload actually received.
  • Gthulhu turns that allocation into a verifiable runtime execution policy without crossing the CPU/resource boundaries Kubernetes already established.

Explore the Claim2Core roadmap