ARM big.LITTLE & DynamIQ Scheduling for Edge AI 2026 — Pinning Inference Across Heterogeneous Cores

Most 2026 ARM edge-AI SoCs are not eight identical cores — they are DynamIQ asymmetric designs that pair a handful of fast cores (Cortex-A76/A78 class) with a cluster of efficiency cores (Cortex-A55 class) sharing one L3. The RK3588 runs 4× A76 + 4× A55; Qualcomm's QCS6490 stacks 1× X1 + 3× A78 + 4× A55; MediaTek Genio 1200 pairs 2× A78 with 6× A55. The promise is "performance when you need it, power when you don't" — but only if the OS scheduler actually puts the right thread on the right core. Inference workloads, with their bursty tensor math and strict latency budgets, are exactly where default scheduling leaves performance on the table. This guide covers how Linux schedules on asymmetric ARM, and how to take control.

The asymmetry problem

A single big core can deliver 2–3× the single-thread throughput of an A55 while drawing proportionally more power; the A55 wins on energy per instruction at light load. The scheduler's job is to match thread demand to core capacity. Linux has done this since mainline 4.7-era energy-aware work matured: EAS (Energy-Aware Scheduling), enabled with CONFIG_ENERGY_MODEL and the schedutil governor, estimates the energy cost of placing a task on each CPU and biases wake-ups toward efficiency cores at low load, migrating heavy tasks up to big cores. On Android this evolved into WALT-based tuning, but on standard embedded Linux EAS plus capacity-aware wake-up logic is what you get out of the box — and it is tuned for average workloads, not for a 5 ms inference deadline.

Why default EAS is not enough for inference

Edge-AI pipelines are periodic and asymmetric: one or two heavy threads (model forward pass), several light threads (capture, preprocess, tracking, comms) and hard real-time-ish deadlines. EAS balances energy and latency by a heuristic weight; a YOLO forward pass can be misclassified as short-lived and land on an A55, tripling latency, or a latency-sensitive thread can be migrated mid-inference. Two mechanisms fix this deterministically: capacity-aware placement (big cores for the compute threads) and partitioning so the scheduler cannot cross-pollinate. In practice this means telling the kernel which CPUs each workload may use, rather than hoping EAS guesses right.

Pinning strategies that work

The three tools, in increasing order of enforcement: taskset pins a process to a CPU mask — taskset -c 4-7 ./inference locks your model threads onto the big cluster of an RK3588 (cores 4–7) while the kernel keeps housekeeping on 0–3. cgroup v2 cpuset partitions at the container level — in Docker, --cpuset-cpus does the same for the whole inference container, which is the pattern that survives orchestration. IRQ affinity (/proc/irq/<n>/smp_affinity) pins camera and network interrupts to specific cores so interrupt storms do not preempt inference threads. A robust production layout: efficiency cores run Linux housekeeping, watchdog, and light preprocessing; big cores run the model; one dedicated big core handles the RT or hard-deadline path; the NPU, not the CPU, takes the heaviest tensor work where the SoC has one.

The Jetson contrast: homogeneous changes the math

NVIDIA's Jetson Orin and Thor modules use homogeneous Arm cores (A78AE / Neoverse V2) — every core is equal, so there is no big.LITTLE asymmetry to schedule around. Pinning still matters, but for a different reason: isolating inference from Jetson's Linux housekeeping and camera stack prevents jitter, not core-type mismatch. On asymmetric RK3588/QCS6490-class boards, by contrast, ignoring core types can silently cost you 30–50% of achievable inference throughput or double your power draw. Measure first: run your model unpinned, then pinned, and compare both latency percentiles and board power — the pinning win is usually visible on both axes.

Practical checklist

Confirm your kernel has EAS and the energy model enabled (CONFIG_ENERGY_MODEL=y, schedutil governor, /sys/devices/system/cpu/cpu*/cpufreq present). Read the cluster layout from /sys/devices/system/cpu/possible and cpu_capacity before assuming core order — big cores are not always 4–7. Pin the inference container with --cpuset-cpus, pin IRQs away from the inference cores, and leave the governor on schedutil rather than forcing performance — letting frequency scale with the NPU/CPU burst usually beats a constant max clock on both power and thermals. Finally, test under load: thermal throttling changes the capacity picture, and a layout that wins at 25°C can lose at 60°C in a sealed enclosure.