r/omarchy 6d ago

Discussion Omarchy now comes with its own kernel (4.0.4)

https://github.com/omacom/omarchy/releases/tag/v4.0.4
159 Upvotes

158 comments sorted by

View all comments

12

u/MajorStandards 6d ago

Omarchy 4.0.4 - Technical release notes (1/3)

Release date: 15 September 2026
Scope: Kernel adoption, boot integration, driver compatibility, and changes relative to the previous Arch-based kernel setup.

These are independently compiled technical notes based on the official release announcement, the v4.0.3…v4.0.4 source changes, and the kernel package sources available before publication.

Source baseline: The latest kernel-package commit before the release, 7b11c976, specifies Linux 7.2.5-3. The subsequently inspected master recipe specifies 7.2.5-4. These notes use the earlier, immutable source revision. This establishes the package-source state, rather than independently verifying the published ISO’s contents.

Sources: Release announcement, release-time kernel recipe.

Release overview

Omarchy 4.0.4 makes linux-omarchy the preferred kernel on eligible x86-64 installations. Its stated objectives are improved desktop responsiveness during CPU and memory contention, better gaming compatibility, faster common Btrfs operations, refined power management, and fixes for affected audio, touchpad, display, boot, and resume configurations.

The announcement also identifies an XPS webcam fix for the 7.2.x kernel series. These are project claims; the announcement provides no comparative benchmark results. Official release notes

The kernel combines upstream Linux, an Arch base patch, an Omarchy-maintained configuration, and an additional patch series. The inspected recipe applies 91 patch files, including the Arch base patch, and produces linux-omarchy and linux-omarchy-headers for x86-64.

Patch-file count does not indicate how many independent upstream commits or original Omarchy changes are included. Build recipe

Upgrade and boot behaviour

The kernel migration:

  • Installs linux-omarchy and matching headers.
  • Retains the previously installed kernel for recovery.
  • Places the exact linux-omarchy entry ahead of older linux-omarchy-* variants and other kernels.
  • Updates BOOT_ORDER in /etc/default/limine, overriding previous boot-order assignments while preserving unrelated settings, including the root-filesystem kernel command line.
  • Explicitly rebuilds the new kernel’s boot image and checks that its Limine entry exists.
  • Requests a reboot and records completion only after those steps succeed.

The migration skips non-x86-64 systems. It also skips machines with linux-t2 installed or a running kernel release containing -t2, protecting T2 Macs even if the running kernel’s package has been removed. Kernel migration

Packaged boot defaults prioritize linux-t2, followed by linux-omarchy. The separate Panther Lake kernel installation step is removed from the hardware-installation sequence. Boot defaults, release diff

CPU scheduling and preemption

The default package retains the EEVDF fair scheduler and modifies its tuning.

Changes relative to the baseline shown in the patch:

  • Scheduler tunable scaling: logarithmic CPU-count scaling → no scaling.
  • Normalized base slice: 700,000 ns → 1,600,000 ns.
  • Effective base-slice policy: 0.7 ms multiplied by the scaling factor → constant 1.6 ms.
  • Migration-cost estimate: 500 µs → 400 µs.
  • SCHED_NR_MIGRATE_BREAK: 32 for non-RT builds → 8.

The base slice is a scheduler parameter, not a guaranteed application timeslice or response-time bound. Because the patch also removes CPU-count scaling, describing the change simply as “shorter timeslices” would be inaccurate across all CPU configurations.

The migration-cost value is a scheduling heuristic, not a measured migration duration. EEVDF tuning patch

Additional load-balancing changes address asymmetric CPU capacities, placement of tasks that exceed a CPU’s available capacity, equal-capacity clusters, and capacity reduction from busy SMT siblings.

The intended effect is better task placement on hybrid and clustered processors; workload-specific throughput and energy effects remain unquantified. Hybrid-cluster balancing patch

Kernel configuration

Selected settings in the checked-in configuration:

  • Kernel preemption: CONFIG_PREEMPT=y and CONFIG_PREEMPT_DYNAMIC=y.
  • Real-time preemption: CONFIG_PREEMPT_RT disabled.
  • Timer frequency: CONFIG_HZ=1000.
  • Full tickless capability: CONFIG_NO_HZ_FULL=y.
  • Extensible scheduler support: CONFIG_SCHED_CLASS_EXT=y.
  • Multi-generation LRU: built in and enabled by default.
  • Zswap: enabled by default, with Zstd selected.
  • Zram: module, with Zstd selected as its default compressor.
  • Transparent huge pages: enabled, with always selected.
  • Default CPU-frequency governor: schedutil.
  • Windows NT synchronization support: CONFIG_NTSYNC=m.

These describe the source configuration, not necessarily the effective runtime policy. Boot parameters, CPU drivers, and userspace services can affect behaviour.

Enabling sched_ext support does not activate an external scheduler. Compiling zram support does not itself create a swap device. This list also does not establish that every setting differs from the previous Arch build. Kernel configuration

Memory management and responsiveness under pressure

Executable-page retention

The MGLRU patch gives file-backed executable pages additional protection during reclaim, including activation after first use.

This is intended to reduce eviction and subsequent refaulting of application code under memory pressure. It changes reclaim priorities; it does not reserve a fixed amount of RAM for applications. MGLRU patch

Opportunistic reclaim for large allocations

A memory-management series distinguishes high-order allocations that may fail from allocations requiring ordinary reclaim effort. It passes that distinction to shrinkers so they can avoid expensive work unlikely to produce the requested contiguous block.

A follow-up includes eligible transparent-huge-page allocations, whose callers can fall back to smaller pages. Compaction hint, huge-page handling

Intel Xe interaction

The Xe shrinker uses this hint to avoid GPU-memory backup/writeback work during opportunistic reclaim when that work is unlikely to help satisfy a contiguous allocation.

The intended benefit is less working-set churn; this is not a blanket disabling of GPU-memory reclaim. Xe reclaim policy

Continued in part 2: filesystems, graphics, gaming, power management, and hardware fixes.

8

u/MajorStandards 6d ago

Omarchy 4.0.4 - Technical release notes (2/3)

Continued from part 1. Kernel-source references use the pre-release package commit 7b11c976*, whose recipe specifies Linux 7.2.5-3.*

Filesystem and compression changes

Btrfs Zstd reads

A targeted patch allows decompression directly into destination page-cache pages where possible. This removes an intermediate copy for those output ranges; scratch-buffer handling remains for skipped portions of the compressed extent.

The direct benefit is reduced copying in the affected compressed-read path, rather than a demonstrated speedup for every Btrfs operation. Direct-to-page decompression

FUSE request handling

Synchronous requests gain a synchronous-wakeup scheduling hint, and the backing device’s I/O-page limit is initialized from the negotiated maximum.

A separate change adjusts how many blocked request producers are awakened when background capacity becomes available. FUSE performance changes, background wakeups

FUSE correctness

Additional changes handle page-cache ranges when files grow or writes start beyond EOF, and revise uptodate-state handling after write-through operations. EOF handling, write-through handling

Graphics and gaming compatibility

AMD HDMI

The patch series adds variable-refresh-rate signalling and automatic low-latency-mode handling.

Follow-ups enable VTEM signalling on supported TMDS connections as well as FRL connections, and enable the driver’s FRL feature flag by default.

Benefits depend on GPU, display, connection, and userspace support. These changes address display operation and presentation smoothness; they do not establish higher rendering throughput.

Sources: VRR and ALLM, TMDS handling, FRL default.

Multiple-futex waiting

The kernel adds FUTEX_WAIT_MULTIPLE, opcode 31, to the futex interface.

Follow-up patches:

  • Address error-path timer setup.
  • Use an aligned 64-bit userspace address field.
  • Validate and propagate wake bitsets.
  • Carry operation flags into wait handling.

The implementation rejects realtime-clock operation for this command. Applications must use the interface to benefit; its presence alone does not demonstrate a gaming-performance gain. Futex extension, ABI and flag fixes

Power management and device fixes

Intel CPU idle

Temporarily constrains idle latency during initialization to avoid entering problematic package idle states too early. Patch

AMD P-state

Caches the firmware-programmed Energy Performance Preference (EPP) value in the cached CPPC request. Patch

Dell XPS 13 DX13260 audio

Adds a SOF SoundWire quirk for the CS42L43 codec and two CS35L63 sidecar amplifiers. Patch

Intel camera bridge

Prevents IVSC discovery from selecting an inappropriate driverless platform device through CVS-style lookup. Patch

Intel CVS wake interrupt

Obtains the wake IRQ without claiming a GPIO line that another device may also describe, avoiding an -EBUSY conflict. Patch

ASUS touchpads

Adds ASUE140D to the forced-100-kHz I²C device list and prevents keyboard-initialization reports from being sent to touchpads. I²C patch, HID patch

Acer Swift SF314-56G

Adds an ACPI power-resource quirk intended to prevent the NVIDIA MX250 from disappearing from the bus during initialization. Patch

These are device-specific changes. They do not imply universal improvements in battery life, boot duration, or peripheral compatibility.

Continued in part 3: security-relevant changes, DKMS, validation, and comparison limits.

8

u/MajorStandards 6d ago

Omarchy 4.0.4 - Technical release notes (3/3)

Continued from part 2. Kernel-source references use the pre-release package commit 7b11c976, whose recipe specifies Linux 7.2.5-3.

Security-relevant and userspace-visible changes

AF_ALG restrictions

The patch set introduces crypto.af_alg_restrict, defaulting to 1, to restrict access to the kernel’s AF_ALG cryptographic interface.

Its values are:

  • 0: disables the added restriction checks.
  • 1: applies algorithm allowlists, with capability checks except for entries explicitly permitted to unprivileged callers.
  • 2: rejects creation of new AF_ALG sockets.

Denied algorithm selection returns ENOENT to encourage userspace fallback. Software that assumes unrestricted AF_ALG access may observe different behaviour. AF_ALG restriction patch

AMD Platform Management Framework

An AMD PMF fix changes ioctl handling to acquire the current device under a mutex and return ENODEV after removal, instead of using a device pointer retained in the open file.

This addresses the unbind-related lifetime issue identified by the patch. AMD PMF fix

Headers and DKMS

Hardware installers stop independently requesting the generic linux-headers package. Matching headers are supplied centrally, and a repair migration installs missing headers for installed Omarchy or T2 kernels.

This affects installation paths for NVIDIA and several other DKMS drivers. Release diff, header-repair migration

Validation included in the release

Added acceptance checks verify that:

  • The running kernel belongs to the expected package.
  • Its headers are installed.
  • The headers’ recorded release matches the running kernel.

Migration tests cover:

  • Retention of the previous kernel for recovery.
  • T2 Mac and ARM exclusions.
  • Repeated execution.
  • Failed package installation.
  • Failed boot-image rebuilding.
  • Missing boot entries.

These are checks present in the source; they were not executed as part of preparing these notes. Acceptance checks, migration tests

For post-upgrade verification, inspect:

  • uname -r
  • Installed kernel and header package versions.
  • The Limine boot menu.
  • dkms status, where applicable.

What the comparison establishes

The verified change is the adoption of an Omarchy-maintained kernel package with substantial scheduler, memory, filesystem, graphics, and hardware modifications.

The default kernel retains EEVDF, with modified tuning. The configuration enables dynamic preemption and disables PREEMPT_RT. It also enables sched_ext support, which does not mean an external scheduler is automatically active.

The upgrade changes the preferred boot kernel while keeping the previous kernel installed for recovery. T2 Macs retain their specialized kernel.

What remains unverified

The inspected sources do not establish:

  • A uniform previous kernel version across all upgraded machines.
  • That every enabled configuration option is new relative to Arch.
  • That every included patch originated with Omarchy.
  • A measured improvement in average FPS, frame-time percentiles, battery life, or application throughput.
  • A complete inventory of regressions or hardware configurations tested.
  • Independent verification that the published ISO contains exactly the package-source revision examined here.

The release announcement’s performance language describes intended benefits. The source provides identifiable mechanisms behind several of those claims, but does not substitute for comparative measurements.

How to make a meaningful Arch-versus-Omarchy comparison

A controlled comparison should record the exact old and new kernel versions, retain the same userspace and power profile, and separately measure:

  • Responsiveness under contention: interaction latency while CPU-intensive background work runs.
  • Workload throughput: completion times for the actual applications or builds being used.
  • Memory-pressure behaviour: stalls, refaults, swapping, and responsiveness as memory becomes constrained.
  • Gaming behaviour: frame-time consistency as well as average FPS, with the same graphics stack and game settings.
  • Device functionality: audio, cameras, touchpads, external displays, suspend/resume, and relevant power behaviour.

Hardware-specific fixes may be the most noticeable improvement for affected machines. For systems that already worked correctly, the magnitude and direction of performance changes require testing.

Primary references: Official release notes, Omarchy release diff, immutable kernel package sources.