Linux Kernel v6.17 is Released: This is What's New for Compute Express Link (CXL)

Linux Kernel v6.17 is Released: This is What's New for Compute Express Link (CXL)

The Linux Kernel v6.17 release brings several improvements and additions related to Compute Express Link (CXL) technology.

Release Highlights

Linux Kernel v6.17 includes 32 commits to the CXL and DAX subsystems:

CategoryCommits
New Features & Hardware1
Bug Fixes6
Refactoring & Cleanup3
Other22

The v6.17 cycle for CXL and DAX is a consolidation release rather than a feature-heavy one, with 32 commits that reflect the subsystem maturing around correctness, specification compliance, and architectural hygiene. The most visible theme is alignment with CXL specification revision 3.2: the Common Event Record has been updated to match the new spec, the Memory Sparing Event Record gains kernel tracing support for the first time, and additional validity checks land for corrected volatile memory error (CVME) counts in both DRAM and General Media Event Records. This work strengthens the kernel’s ability to correctly interpret and surface CXL RAS events to userspace tooling and monitoring infrastructure.

A quieter but structurally important change is the removal of core/acpi.c and the CXL core’s direct dependency on ACPI. This decoupling makes the CXL core more portable and easier to reason about — the ACPI glue now lives where it belongs rather than being tangled into the driver core. Alongside this, the node-notifier migration replaces the older memory-notifier pattern, bringing CXL memory hotplug handling in line with current kernel conventions for NUMA-aware memory event signaling.

Locking correctness receives explicit attention this cycle: both the conditional rwsem locking paths and the poison list mutex are converted to use ACQUIRE() semantics, ensuring proper memory ordering on architectures where weak ordering would otherwise permit reordering across these critical sections. Several targeted bug fixes round out the release, addressing a typo in the MCE notifier registration, an ERR_PTR vs NULL confusion in region handling, wrong DPA bounds checking for PPR operations in the EDAC path, and a format specifier mismatch for u32 values.

Key Changes

  • CXL Spec 3.2 Event Record Compliance: The Common Event Record structure is updated to match CXL spec rev 3.2, and validity checks are added for CVME counts in both DRAM and General Media Event Records, ensuring the kernel correctly handles fields that older firmware may leave unset.

  • Memory Sparing Event Record Tracing: Kernel tracepoints are added for the CXL Memory Sparing Event Record, making sparing operations visible through the standard trace_event infrastructure — essential for diagnosing DRAM sparing activity on CXL memory devices in production.

  • ACQUIRE() Locking Semantics: Conditional rwsem acquisition paths and the poison list mutex are converted to use explicit ACQUIRE() ordering, fixing potential memory ordering hazards on weakly-ordered architectures without adding unnecessary full barriers.

  • ACPI Dependency Removal from CXL Core: core/acpi.c is removed and the CXL core’s direct compile-time dependency on CONFIG_ACPI is eliminated, making the subsystem cleaner to build in non-ACPI environments and reducing coupling between platform firmware abstractions and driver internals.

  • Node-Notifier Migration: CXL switches from the legacy memory-notifier to the node-notifier interface for memory hotplug events, aligning with current kernel practice for NUMA-aware memory device management.

  • cxl_resource_contains_addr() Helper: A new helper function centralizes address-in-resource containment checks, replacing open-coded comparisons across the driver with a single, testable predicate — immediately used in the region probing path.

  • EDAC PPR DPA Fix: Incorrect DPA bounds checking in the EDAC path for Post Package Repair operations is corrected, preventing the driver from operating on wrong address ranges during repair sequences — a silent correctness bug with potential data integrity implications.

  • Region Commit/Detach Consolidation: cxl_decoder_kill_region() and cxl_region_detach() are merged into a single code path, eliminating duplicated teardown logic that was a maintenance hazard and a source of subtle divergence between the two flows.

Here is the detailed list of all commits merged into the 6.17 Kernel for CXL and DAX. This list was generated by the Linux Kernel CXL Feature Tracker .

Tags:

I Added a Feature to OrcaSlicer to Show Travel Distance and Moves

I Added a Feature to OrcaSlicer to Show Travel Distance and Moves

OrcaSlicer is a powerful and popular slicer for 3D printers, known for its rich feature set and active development community. In this blog post, we’ll take a closer look at a new feature I proposed and implemented that provides more insight into your prints: the display of total travel distance and the number of travel moves. See the feat: Display travel distance and move count in G-code summary for more details.

Read More
An Introduction to Generative Prompt Engineeering

An Introduction to Generative Prompt Engineeering

Introduction

Over the past few years, there has been a significant explosion in the use and development of large language models (LLMs). An LLM is a language model consisting of a neural network with many parameters (commonly multi-billions of weights), trained on large quantities of text. Some of the most popular large language models are: GPT-3 (Generative Pretrained Transformer 3) – developed by OpenAI ; BERT (Bidirectional Encoder Representations from Transformers) – developed by Google; RoBERTa (Robustly Optimized BERT Approach) – developed by Facebook AI; T5 (Text-to-Text Transfer Transformer) – developed by Google. Many others exist and continue to emerge. These language models are designed to understand and generate natural language text, allowing for a wide range of applications such as chatbots, content creation, language translation, and more.

Read More
How Much RAM Could a Vector Database Use If a Vector Database Could Use RAM

How Much RAM Could a Vector Database Use If a Vector Database Could Use RAM

Featured image generated by ChatGPT 4o model: “a low poly woodchuck by a serene lake, surrounded by mountains and a forest with tree leaves made from DDR memory modules. The woodchuck is munching on a memory DIMM. The only memory DIMM in the image should be the one being eaten.”

How Much RAM Could a Vector Database Use If a Vector Database Could Use RAM?

Although the title is a punn from the famous “woodchuck rhyme,” the question is serious for LLM applications using vector databases. As large language models (LLMs) continue to evolve, leveraging vector databases to store and search embeddings is critical. Understanding the memory usage of these systems is essential for maintaining performance, response times, and ensuring system scalability.

Read More