KRN-201 · Linux Kernel Core
Process Lifecycle & Scheduling
How processes are created, scheduled and destroyed, and how scheduling decisions show up as latency in your application.
Who this course is for
Developers and performance engineers whose applications live or die by scheduling behaviour — and who want to reason from task_struct and scheduler traces rather than folklore.
Prerequisites
Course outline
Day 1 — The task as a data structure
- task_struct and thread_info: what the kernel keeps per task
- The process family tree, PID namespaces and /proc views
- Threads vs processes in the kernel: it is tasks all the way down
- Kernel threads and their role
- Reading /proc/<pid> against the structures it reflects
Day 2 — Creation and destruction
- fork, clone and clone3: what is shared vs copied, flag by flag
- Copy-on-write mechanics at fork
- execve: replacing the address space and starting over
- exit, zombies and reparenting
- ptrace as an observer of the lifecycle
Day 3 — Scheduling classes and policies
- The scheduling classes: stop, deadline, RT, fair, idle
- Priorities and policies: nice, SCHED_FIFO, SCHED_RR, SCHED_DEADLINE
- The runqueue and the pick-next path
- Where preemption points come from
- What a scheduler class change actually does to a workload
Day 4 — Blocking, waking and the cost of switching
- Context-switch cost and what drives it: cache, TLB, FPU state
- Wait queues, completions and blocking behaviour
- Wake-up paths and thundering herds
- Measuring wakeup-to-run latency with ftrace and perf sched
- Reading sched tracepoints to explain a latency spike
Hands-on labs
Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach
- Lab: watch fork/exec/exit with strace and ftrace, matching every userspace call to its kernel path
- Lab: measure context-switch cost while varying working-set size and CPU count, and explain the curve you get
- Lab: run competing tasks under nice levels and RT policies (chrt) and observe who actually runs
- Lab: instrument the wake-up path with ftrace (sched_wakeup, sched_switch) and measure wakeup-to-run latency
- Lab: reproduce a convoy or thundering-herd effect and make it visible in scheduler traces
Capstone project
Given a latency complaint about a multi-process service, produce an evidence-based diagnosis: scheduler traces showing wakeup-to-run delays, a breakdown of what drives the context-switch cost, policy and priority changes with before/after latency distributions, and a rollback plan — in the format you would hand to a review board.
What you leave with
- Source-level understanding of the task lifecycle from clone to exit
- Working scheduler tracing with ftrace and perf sched
- Correct, sceptical use of priorities and scheduling policies
- Latency evidence you can defend in front of others
How it runs
Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.
Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.
Questions
Who is this course for?
Developers and performance engineers whose applications live or die by scheduling behaviour — and who want to reason from task_struct and scheduler traces rather than folklore. It sits at practitioner level within the Linux Kernel Core track.
What do I need to know already?
Specific prerequisites for this course: Solid C; Userspace systems programming (fork, exec, wait); KRN-101-level source navigation. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.
Can this run privately for my team?
Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.
What is the difference between in-person and online?
In person is 4 full days with hardware on your desk, capped at 14. Online is 8 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.
Do you invoice companies?
Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.
Upcoming dates
| Dates | Where | Seats | Early bird | Regular | |
|---|---|---|---|---|---|
| 8 Nov – 11 Nov 20264 full days | RiyadhIn person · KAFD Conference Centre | 4 of 14 | SAR 9,450until 9 Oct | ||
| 15 Nov – 18 Nov 20264 full days | Kuwait CityIn person · Al Hamra Tower | 9 of 14 | KWD 780until 16 Oct | ||
| 15 Nov – 18 Nov 20264 full days | MuscatIn person · Knowledge Oasis Muscat | 4 of 14 | OMR 970until 16 Oct | ||
| 22 Nov – 1 Dec 20268 half-days | Gulf bandLive online · 09:00–13:00 GMT+3 | 16 of 20 | US$1,800until 23 Oct | ||
| 23 Nov – 26 Nov 20264 full days | OttawaIn person · Kanata North Tech Park | 9 of 14 | CAD 3,430until 24 Oct | ||
| 23 Nov – 2 Dec 20268 half-days | Europe bandLive online · 09:00–13:00 CET | 5 of 20 | US$1,800until 24 Oct | ||
| 30 Nov – 3 Dec 20264 full days | TorontoIn person · MaRS Discovery District | 4 of 14 | CAD 3,430until 31 Oct | ||
| 30 Nov – 3 Dec 20264 full days | LondonIn person · Shoreditch Works | 9 of 14 | GBP 1,960until 31 Oct | ||
| 30 Nov – 9 Dec 20268 half-days | Americas bandLive online · 13:00–17:00 ET | 10 of 20 | US$1,800until 31 Oct | ||
| 7 Dec – 10 Dec 20264 full days | BerlinIn person · Factory Görlitzer Park | 4 of 14 | EUR 2,320until 7 Nov |
Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.
More in Linux Kernel Core
KRN-1013 days
Kernel Architecture & Source Navigation
A guided tour of the kernel tree: how it is organised, how subsystems relate, and how to find the code you need.
Practitioner-taught
SAR 6,750Next 18 Oct
KRN-1022 days
Building & Configuring the Kernel
Configure, build, install and boot a kernel you compiled yourself, and understand what the thousands of config options actually do.
Practitioner-taught
SAR 4,500Next 18 Oct
KRN-1103 days
Modules & the Kernel Build System
Kbuild, module loading, symbol resolution and the module lifecycle from insmod to rmmod.
Practitioner-taught
SAR 6,750Next 15 Nov
KRN-2103 days
CFS to EEVDF Internals
The fair scheduler in depth, the move to EEVDF, and what changed for latency-sensitive workloads.
Practitioner-taught
SAR 9,000Next 18 Oct
KRN-2112 days
CPU Isolation & Affinity
Taking CPUs away from the kernel for latency-critical work: isolcpus, nohz_full, RCU offload and the gotchas.
Practitioner-taught
SAR 6,000Next 25 Oct
KRN-2204 days
Virtual Memory & Page Tables
Address spaces, page tables, faults and mappings — the machinery behind every memory access your program makes.
Practitioner-taught
SAR 10,500Next 22 Nov
KRN-2213 days
Allocators: Buddy, Slab, vmalloc
How the kernel allocates memory at every scale, and how allocator behaviour surfaces as fragmentation and latency.
Practitioner-taught
SAR 9,000Next 22 Nov
KRN-2223 days
Memory Pressure, OOM & cgroup v2
What happens when memory runs out: reclaim, swap, the OOM killer, and cgroup v2 limits that throttle silently.
Practitioner-taught
SAR 9,000Next 22 Nov
KRN-2303 days
Kernel Locking Primitives
Every locking primitive the kernel offers, when each is correct, and the deadlocks that follow from choosing wrong.
Practitioner-taught
SAR 7,880Next 8 Nov
KRN-2313 days
RCU in Depth
Read-copy-update from first principles: grace periods, publish-subscribe, and why RCU is everywhere in the kernel.
Practitioner-taught
SAR 9,000Next 8 Nov
KRN-2323 days
Memory Barriers & the Kernel Memory Model
The hardest correctness topic in the kernel: reordering, barriers, and reasoning about concurrent code that actually holds.
Practitioner-taught
SAR 10,120Next 8 Nov