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

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

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

Release Highlights

Linux Kernel v7.1 includes 47 commits to the CXL and DAX subsystems:

CategoryCommits
New Features & Hardware1
Bug Fixes5
Refactoring & Cleanup5
Testing1
Other35

The v7.1 CXL/DAX cycle is defined by three interlocking themes: laying the groundwork for Type 2 accelerator support, hardening the DAX/HMEM subsystem against a cluster of correctness bugs, and a focused refactoring of the region layer that splits a monolithic file into purpose-specific translation units. None of these is a headline splash feature on its own, but together they represent the kind of steady, unglamorous investment that makes the subsystem reliable enough to build production systems on.

Type 2 support — CXL devices that expose accelerator-attached memory rather than pure memory expanders — takes a significant step forward. Internal structures previously locked inside cxl_pci are now exported so that out-of-tree and in-tree Type 2 drivers can bind against them, and cxl_dev_state initialization now accounts for the Type 2 device class from the start. Alongside this, generic PCI utility code migrates from cxl_pci into core/cxl_pci, giving both the core and Type 2 drivers a shared, stable foundation without duplication.

On the DAX/HMEM side, this release resolves a longstanding ambiguity around Soft Reserved memory ownership — the question of whether a given ACPI-advertised memory range belongs to CXL region management or to the legacy dax_hmem driver. A new containment helper in cxl/region allows that decision to be deferred and resolved cleanly at driver bind time rather than at boot, eliminating a class of singleton confusion bugs and fixing a dependency ordering issue between dax/cxl and dax/hmem that could cause incorrect initialization ordering in multi-device configurations.

Key Changes

  • Type 2 accelerator device support: Internal CXL structs are now exported to allow external Type 2 drivers to participate in the CXL stack, and cxl_dev_state initialization correctly identifies Type 2 devices. This is a prerequisite for CXL-attached accelerators (GPUs, FPGAs, smart NICs) to interoperate with the kernel’s memory management and RAS infrastructure.

  • 32-switch decoder support: cxl/hdm now supports up to 32 switch-level decoders, up from the previous limit. This matters for large fabric topologies — multi-host CXL switches in disaggregated memory configurations — where the old cap became a real constraint.

  • Soft Reserved ownership resolution: A new helper checks whether a Soft Reserved EFI memory range is already covered by a CXL region, and dax_hmem defers claiming those ranges until CXL binding has had a chance to run. This eliminates a race where dax_hmem could steal memory that the CXL region driver was entitled to manage.

  • Region lock status sysfs interface: A new sysfs attribute exposes whether a CXL region is locked, giving userspace tools (and udev rules) a reliable, race-free way to query region state without parsing kernel log output.

  • Region code split into region_dax.c and region_pmem.c: The DAX and PMEM region driver logic is extracted from a single sprawling file into two focused translation units. This is maintenance work, but it reduces the cognitive overhead for contributors working on only one media type and makes future specialization easier.

  • PCI reset decoder flag clearing: When a cxl_memdev undergoes a PCI-level reset, endpoint decoder flags are now explicitly cleared. Without this, stale flag state could cause the driver to misinterpret post-reset device status, leading to incorrect region assembly or missed error events.

  • Use-after-free fix in region auto assembly: A reference-counting bug in the region auto-assembly failure path could cause a freed region object to be accessed during cleanup. The fix ensures teardown ordering is correct and is a straightforward but important memory safety correction.

  • fsdev_dax_zero_page_range() uninitialized kaddr fix: A missing initialization in the DAX filesystem zero-page path left kaddr undefined under certain conditions, producing unpredictable behavior when zeroing page ranges through a DAX-mapped filesystem. The fix initializes kaddr unconditionally before use.

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

How To Monitor Persistent Memory Performance on Linux using PCM, Prometheus, and Grafana

How To Monitor Persistent Memory Performance on Linux using PCM, Prometheus, and Grafana

In a previous article, I showed How To Install Prometheus and Grafana on Fedora Server . This article demonstrates how to use the open-source Process Counter Monitor (PCM) utility to collect DRAM and Intel® Optane™ Persistent Memory statistics, and visualize the data in Grafana.

Processor Counter Monitor is an application programming interface (API) and a set of tools based on the API to monitor performance and energy metrics of Intel® Core™, Xeon®, Atom™ and Xeon Phi™ processors. It can also show memory bandwidth for DRAM and Intel Optane Persistent Memory devices. PCM works on Linux, Windows, Mac OS X, FreeBSD and DragonFlyBSD operating systems.

Read More
How To Verify Linux Kernel Support for Persistent Memory

How To Verify Linux Kernel Support for Persistent Memory

Linux Kernel support for persistent memory was first delivered in version 4.0 of the mainline kernel, however, it was not enabled by default until version 4.2.

If you use a Linux distribution that uses kernel 4.2 or later, or the distro backports features in to an older kernel, you will almost certainly have persistent memory support enabled by default. It is still worth verifying what features are enabled and disabled as this may vary by distro and release version for the very latest persistent memory features.

Read More
Fastfetch: The Speedy Successor Neofetch Replacement Your Ubuntu Terminal Needs

Fastfetch: The Speedy Successor Neofetch Replacement Your Ubuntu Terminal Needs

If you love customizing your Linux terminal and getting a quick, visually appealing overview of your system specs, you might have used neofetch in the past. However, neofetch is now deprecated and no longer actively maintained. A fantastic, actively maintained alternative is Fastfetch – known for its speed, extensive customization options, and feature set.

While you might be able to install Fastfetch on Ubuntu 22.04 (Jammy Jellyfish) using the standard sudo apt install fastfetch, the version available in the default Ubuntu repositories is often outdated. To get the latest features, bug fixes, and performance improvements, you’ll want to use a different method.

Read More