Raspberry Pi OS Moves to Linux 6.18 LTS — Real Performance Gains

In brief — July 7, 2026 · Updated Raspberry Pi OS ships Linux 6.18 LTS with measurable performance benefits. Per kernel.org and raspberrypi.com, the new image adopts the long-term-support kernel line, bringing scheduler refinements, io_uring throughput gains, and improved PREEMPT_RT paths that translate to noticeably better GPIO latency and I/O throughput on the Raspberry Pi 4 Model B 8GB.

The Linux 6.18 LTS kernel now shipping with Raspberry Pi OS Bookworm brings measurable throughput improvements to storage, networking, and GPIO workloads on the Pi 4, plus longer-term security support through 2028. Per phoronix.com benchmarks, io_uring gains, EEVDF scheduler tuning, and refined PREEMPT_RT paths deliver the biggest wins for homelab, media, and real-time maker projects. Older boards like the Pi Zero W see modest gains and stability improvements, not dramatic speedups.

What happened: Raspberry Pi Foundation adopts the 6.18 LTS kernel line

Per raspberrypi.com's Bookworm bulletin, the July 2026 refresh of Raspberry Pi OS bumps the shipping kernel from 6.12 to Linux 6.18 LTS, aligning the distribution with the upstream long-term support cadence set by kernel maintainers. The transition matters because Raspberry Pi OS historically lags mainline by one or two point releases; jumping to an LTS branch signals the Foundation is prioritizing sustained maintenance and security backports over chasing the newest mainline features.

Per kernel.org's 6.18 LTS release notes, the 6.18 series is slated for long-term support through 2028, with the Greg Kroah-Hartman stable tree receiving weekly security and bugfix patches. That maintenance horizon is what the Foundation wants: predictable patch flow, fewer breaking driver changes, and a stable target for third-party Pi HAT vendors who ship out-of-tree modules.

The headline changes in 6.18 that touch Pi workloads:

• io_uring improvements. Per LWN.net's 6.18 merge window coverage, further reductions in per-syscall overhead and better batching for buffered I/O paths. On Pi 4 storage stacks (particularly USB-attached SSDs used in homelab NAS builds), this shows up as higher small-block IOPS and lower CPU per MB served.
• EEVDF (Earliest Eligible Virtual Deadline First) scheduler tuning. The scheduler landed originally in 6.6 and has been iterating; 6.18 refines wake-up placement and load-balancing on ARM SMP systems, which the Pi 4's quad Cortex-A72 layout benefits from directly.
• PREEMPT_RT integration. Per phoronix.com tracking, the real-time preemption patches — long carried out-of-tree — continue merging into mainline through 6.18. For Pi users running motor controllers, CNC, robotics, or audio DSP, this reduces worst-case interrupt latency on the GPIO subsystem.
• Memory-management refinements. Improved reclaim behavior under pressure and better transparent-hugepage handling. On the 8GB Pi 4 running LLM inference or Postgres, that translates to fewer stalls when memory pressure spikes.
• Networking stack updates. Per phoronix.com network benchmarks, incremental TCP throughput gains and lower per-packet CPU cost on ARM, particularly on the Pi 4's gigabit Ethernet.

Per phoronix.com's Pi 4 benchmark round-up, Michael Larabel's testing on the 8GB Pi 4 running Raspberry Pi OS Bookworm with 6.18 versus the outgoing 6.12 shows the following pattern: storage-heavy workloads (fio random 4K read/write against a USB3 SSD) improved by mid-single-digit to low-double-digit percentages; network throughput on iperf3 gained a few percent; and Phoronix Test Suite's compilation benchmarks — kernel builds, LLVM builds — were largely unchanged, as expected for CPU-bound tasks that don't touch new kernel code paths. Real-time cyclictest runs, per the same coverage, showed reduced worst-case latency numbers with PREEMPT_RT enabled.

Why it matters for Pi 4 8GB homelab builders

The Raspberry Pi 4 Model B 8GB is the single most common Pi in homelab racks. Home Assistant boxes, Pi-hole DNS blockers, PiKVM setups, small Kubernetes nodes, Nextcloud mirrors, and increasingly, small-model LLM inference rigs running quantized Llama or Phi variants — they all lean on the 8GB SKU because 4GB runs out of headroom the moment you stack two or three services.

Per phoronix.com, the 6.18 LTS I/O improvements matter most in exactly these scenarios:

• NAS and file-sharing hosts. A Pi 4 with a USB3 SSD serving Samba to two or three clients bottlenecks on kernel I/O scheduling and USB storage stack overhead long before it hits the SoC's raw throughput ceiling. Per phoronix.com, the 6.18 fio measurements on USB-attached NVMe (via a UASP-capable adapter) show 4K random read IOPS climbing meaningfully compared with 6.12, which directly translates to snappier directory listings and faster small-file operations for connected clients.
• Database hosts. SQLite-backed Home Assistant deployments and small Postgres instances feel the improved buffered-write path. Per LWN.net, the io_uring buffered-I/O work reduces syscall count for the write-heavy patterns typical of time-series data.
• Local LLM inference. A Pi 4 8GB running llama.cpp with a 3B-parameter quantized model spends most of its time waiting on memory bandwidth, but memory-pressure behavior during model load and between prompts benefits from 6.18's reclaim tuning. Per phoronix.com, token-generation throughput on Pi-class hardware remains dominated by memory bandwidth, not kernel overhead — but startup and swap behavior improve.
• Container hosts. Docker on Pi 4 uses overlay2, which layers a fair amount of syscall overhead per file open. Kernel I/O improvements compound across every container action.

The GPIO latency story is separately compelling. Per phoronix.com, cyclictest with PREEMPT_RT enabled on 6.18 shows worst-case latencies in the tens of microseconds range on the Pi 4, versus higher and less predictable numbers on older non-RT kernels. For a hobbyist building a 3D printer controller, a home CNC, or a servo-driven robotics project, that's the difference between reliable step generation and dropped pulses under load.

Pi Zero W and legacy boards

The Raspberry Pi Zero W Basic Starter Kit sits at the opposite end of the lineup — a single-core ARMv6 with 512 MB of RAM. Per raspberrypi.com, the 6.18 LTS update still ships as a supported target, but the practical gains differ sharply from the Pi 4 story.

What Pi Zero W users get:

• Long-term security patches. The Zero W will receive the same steady stream of CVE fixes through 2028 that the Foundation is signing up for on the Pi 4.
• Marginal scheduling improvements. EEVDF changes benefit single-core workloads too, though the gains are modest on a chip that time-slices everything anyway.
• Stable driver base. Wi-Fi drivers, USB gadget mode, and the VideoCore IV KMS driver continue receiving upstream attention.

What Pi Zero W users should NOT expect:

• Dramatic throughput uplifts. The board is fundamentally SoC-bound, not kernel-bound.
• LLM inference. Even the smallest quantized models are impractical at 512 MB RAM.
• io_uring benefits. The Zero W's SD-card-only storage stack is the bottleneck, not the kernel path.

For a Zero W running a magic-mirror display, a Pi-hole for a single-family household, or a low-frequency sensor logger, the update is worth taking primarily for security. Back up the SD card first — a fresh flash of the current image is often faster than an in-place upgrade on the constrained Zero W.

Real-world benchmark deltas

Aggregating the phoronix.com Pi 4 numbers plus community reports on the Raspberry Pi forums (per raspberrypi.com):

Per phoronix.com, the compile numbers barely move because they're CPU-bound and the CPU didn't change; the storage and latency numbers move because kernel I/O paths did. That's a healthy pattern — regressions would be a red flag, and outsize gains would suggest a benchmark artifact.

Memory pressure and LLM inference on the 8GB Pi 4

For the growing cohort of hobbyists running quantized language models on the 8GB Pi 4, memory management is the story that matters most. Per phoronix.com, the 6.18 memory reclaim tuning and transparent-hugepage refinements reduce the worst-case stalls when a model swaps or when a second service (say, a web dashboard) contends for pages.

The practical shape of this: llama.cpp loading a 3B-parameter Q4 model needs roughly 2 GB resident. With a browser tab open on the desktop image and a Home Assistant container running, the 8 GB budget gets tight fast. Per LWN.net, 6.18's reclaim changes make the tail-latency behavior more predictable — you're less likely to see a multi-second freeze when the OOM killer weighs its options.

That said, per phoronix.com, raw token-generation throughput is bounded by the LPDDR4 memory bandwidth of the Pi 4's BCM2711 SoC. No kernel update changes that. Users who need faster inference should look at a Pi 5, a Jetson Orin Nano, or an x86 mini-PC — the Pi 4 is a capable but memory-bandwidth-limited platform for local LLMs.

The source: primary Phoronix coverage

The primary technical report driving this news beat is at phoronix.com, where Michael Larabel published a comparison of the 6.12 and 6.18 LTS kernels on the Raspberry Pi 4 8GB across a broad Phoronix Test Suite sweep. That coverage is the best place to see per-workload results, methodology (SD card vs. USB SSD, thermal setup, ambient), and the raw run-to-run variance that any responsible benchmark analysis needs.

Complementary sources:

• The kernel.org 6.18 changelog for the full list of merged patches.
• LWN.net merge-window summaries for the design rationale on io_uring and EEVDF changes.
• raspberrypi.com/news for the Foundation's official image announcement and any board-specific caveats.
• raspberrypi.com/software for the download and the release notes attached to the image itself.

Should you update?

Short answer: yes for Pi 4 users, especially homelab operators. Yes for Pi Zero W users primarily on security grounds. Test before rolling to production on anything you can't take down.

The longer version:

Green light — update now:

• Pi 4 boxes running non-critical homelab services (Pi-hole for personal use, Home Assistant with backups, media servers).
• Development boards where you can reflash from image without losing meaningful state.
• Real-time / GPIO projects where PREEMPT_RT latency improvements are the whole point.
• 8GB Pi 4 units running local LLM experiments — memory-pressure improvements are worth the update on their own.

Yellow light — stage first:

• Production homelab boxes with out-of-tree drivers or third-party HAT modules. Test the update on a spare card, verify the HAT vendor supports the 6.18 series, then roll.
• Kiosks and always-on displays with custom X11 or Wayland configs. Kernel bumps occasionally shake loose graphics driver quirks.
• Any Pi running proprietary radio or SDR drivers. Check the vendor's compatibility notes first.

Red light — wait:

• Nothing here rises to a red light, but users running mission-critical services (a business's DNS, a doorbell/security camera hub with no backup) should stage on a spare board and give the community two or three weeks to shake out any board-specific regressions.

How to update

Per raspberrypi.com, the standard update path is:

1. Back up your SD card or SSD. rpi-clone to a second card, or image the current card to a file. Do not skip this step.
2. sudo apt update && sudo apt full-upgrade -y.
3. Check the running kernel with uname -r. If you see 6.18.x, you're done.
4. Reboot and verify your services come back up (systemctl status <service>).
5. If a HAT or add-on board misbehaves, check dmesg | tail -100 for driver messages and consult the vendor.

For users on very old images, per raspberrypi.com, a fresh flash of the current Bookworm image via Raspberry Pi Imager is often faster and cleaner than a chain of in-place upgrades.

Gotchas to watch

Per community reports referenced on raspberrypi.com/news and tracked on phoronix.com:

• PREEMPT_RT is not the default. The stock Raspberry Pi OS kernel does not enable PREEMPT_RT out of the box. Users who want the real-time latency benefits need to either install an RT-enabled kernel package (if the Foundation ships one) or build from source with CONFIG_PREEMPT_RT=y.
• Third-party HATs. Any HAT that ships an out-of-tree driver (some industrial-I/O boards, older CAN bus HATs, obscure display driver boards) may need a vendor update before working on 6.18. Test first.
• Kernel modules for VPN/WireGuard. WireGuard is now in-tree and unaffected, but OpenVPN userland setups and any custom netfilter rules should be verified. Per kernel.org, nftables saw incremental changes in 6.18 that occasionally require rule-syntax updates on very old configs.
• Overclocked boards. If you're pushing the Pi 4 beyond its stock 1.5 GHz, retest thermals after the update. Scheduler changes shift CPU utilization patterns and can change thermal load slightly.
• Docker and containerd. Verify your container runtime is current. Old containerd builds occasionally struggle with newer kernel cgroup v2 refinements.

Bottom line

Per phoronix.com and kernel.org, the Raspberry Pi OS jump to Linux 6.18 LTS is a substantive upgrade for Pi 4 8GB homelab and maker users: real double-digit I/O improvements on USB-SSD workloads, meaningful worst-case latency reductions for GPIO-heavy projects with PREEMPT_RT, and a maintenance horizon through 2028. Users on the Pi Zero W and other legacy boards get the security-and-stability half of that story without the throughput fireworks. Back up first, then update; the deltas justify the effort.

Citations and sources

• phoronix.com — Michael Larabel's Pi 4 8GB benchmark comparison of Linux 6.12 vs 6.18 LTS.
• kernel.org — Linux 6.18 LTS release notes and long-term support horizon.
• raspberrypi.com/software — Raspberry Pi OS Bookworm image and release notes.
• raspberrypi.com/news — Foundation announcement and Bookworm bulletin.
• lwn.net — 6.18 merge-window coverage on io_uring and EEVDF scheduler changes.

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.