Hi, it seems that the browser you're using is not compatible with my site. Either because it's too old or you're using one of the following browsers:

More importantly, I got you :-), Here is a backwards compatible version that is designed to work on older or no-javascript browsers classic.richardorilla.website

Table of Contents

Optimizing a Typical Linux Distro for Desktop Responsiveness

Introduction

One thing I have noticed over the years of using Linux as my main desktop operating system is that a lot of mainstream distros feel like they are tuned first for being broadly correct rather than specifically pleasant on a personal computer.

And to be clear, I do not mean this as some cheap jab against Fedora, Ubuntu, Arch, or whatever distribution you happen to use. These are not bad operating systems. In fact, part of why they are so good is because their defaults are safe, predictable, and broad enough to work across many different kinds of hardware and workloads.

The problem is that the “broadly correct” default is not always the same thing as “best for desktop responsiveness.”

A typical desktop user does not really care if a certain default squeezes a bit more throughput out of the storage stack, if the kernel allows a bit more dirty data to build up before flushing it, or if memory pressure is tolerated a bit longer before something gets killed. What the desktop user notices instead is this:

This is where I think many Linux distros still show their general-purpose roots.

Unlike something like SteamOS, which is built around a very specific hardware target and a very specific use case, the average Linux desktop distro has to be a compromise. It has to run on laptops, workstations, desktops, virtual machines, and even setups that are not really desktop-oriented at all. So naturally, it ships with defaults that are “good enough” across the board.

But that does not mean we cannot tune it further.

And that is really the point of this article.

This article is not about turning Linux into some unstable Frankenstein build full of random internet sysctl snippets and placebo boot parameters. It is about making deliberate changes that trade a bit of the throughput-oriented, general-purpose, or server-friendly behavior for something that feels better on an actual desktop machine.

In particular, I want to focus on the things that matter most when a machine is under stress:

The idea here is simple: I am willing to give up a bit of theoretical peak performance if it means my desktop remains responsive in low-memory or busy situations.

Because at the end of the day, that is what a desktop machine is supposed to do.

Definition of Terms

Before we begin, I would like to clarify the terminology used throughout this article:

The Problem with General-Purpose Defaults

I think one mistake people often make when tuning Linux is immediately assuming that desktop sluggishness must be a CPU scheduling problem.

In practice, that is often not the real issue.

Modern Linux already has a competent CPU scheduler. For a lot of normal desktop use, it is not as though the kernel is clueless about how to distribute CPU time fairly. The real pain points tend to show up elsewhere: memory reclaim, storage contention, swap behavior, writeback, and sometimes graphics saturation.

This is why you can have a Linux system that benchmarks perfectly fine and still feels annoying in real-world use.

For example, a distro may be perfectly happy to let a large amount of dirty data pile up in RAM before flushing it. On paper, this can be good for throughput. In actual desktop use, however, it can also mean that once the flush starts hitting hard, the desktop suddenly feels awful. Likewise, a distro may ship with a tiny swap file or no useful compressed swap layer, which means once memory pressure rises, the system has fewer graceful ways to absorb it. And on the graphics side, the system may behave fine in normal use but still feel miserable once the GPU that is driving the desktop gets saturated by a heavy workload.

This is what I mean when I say many Linux distros feel tuned more like general-purpose systems than desktop-first systems.

That is not the same as saying they are “for servers only.” It is more accurate to say that their defaults are conservative and broad, whereas a desktop user usually has a narrower goal: keep the machine pleasant under stress.

Start with zram

If there is one tweak I think deserves to be treated as foundational for desktop responsiveness, it is zram.

The reason is simple. zram gives the system a fast, compressed memory-backed place to put less-active pages before it has to go to slower disk swap. In other words, instead of the machine immediately degrading into ugly reclaim behavior or slamming the disk, it gets another layer of breathing room first.

For desktop use, this is huge.

A lot of responsiveness problems do not begin when the system is fully out of memory. They begin earlier, when memory pressure starts rising and the system has to make tougher decisions about what stays hot in RAM and what gets pushed out. zram helps soften that transition.

This is why I consider zram one of the best “first upgrades” to a normal Linux desktop install. It changes the shape of memory pressure from something abrupt and ugly into something that is often much more survivable.

For a practical setup, I prefer starting conservatively:

				
[zram0]
zram-size = min(ram / 2, 4096)
compression-algorithm = zstd
swap-priority = 100

This gives you a moderate compressed swap layer without going overboard. It is not trying to replace real swap entirely. It is trying to provide a fast first buffer.

For many systems, that alone already improves how the machine behaves when multiple browser tabs, background tasks, and memory-heavy applications collide.

Keep a Real Swap File Too

One thing I do not agree with is the idea that zram means disk-backed swap is no longer necessary.

I prefer keeping both.

zram is about speed. A swap file is about capacity and survivability.

If memory pressure is only brief, zram may be enough to keep the system responsive until the pressure drops. But if the pressure is sustained, or if the workload is simply too large, then the machine still benefits from having a proper swap file to absorb overflow.

This is why I like the layered approach:

  1. RAM first
  2. zram second
  3. disk swap last

That way the system tries the fast options first but still has somewhere to go when the pressure continues rising.

As for sizing the swap file, I do not think there is a universally sacred number. But for a normal modern desktop, I think a tiny swap file is one of the easiest ways to sabotage responsiveness under load.

A practical rule of thumb I would start with is this:

The exact numbers will vary depending on RAM size and workload, but the general principle is the same: zram is not your excuse to remove all real swap.

OOM Killers as the Last Safety Net

Even with zram and a proper swap file, there are still situations where the machine needs help making a decision.

That is where something like earlyoom comes in.

The reason I like earlyoom is that it is a simple userspace OOM killer. The config is also very straightforward and easy to understand.

If a browser, Chromium-based app, Electron app, or some runaway workload is eating memory aggressively, I would rather lose that process than have KWin, Plasma, Xwayland, audio, and general interactivity all collapse into a half-dead state.

A practical config I like is something along these lines:

				
EARLYOOM_ARGS="-m 5 -s 5 -k -n \
  --prefer '(^|/)(chrome|chromium|firefox|electron)' \
  --avoid '(^|/)(kwin_wayland|plasmashell|Xwayland|systemd|dbus-daemon)$'"

The idea is not that earlyoom should constantly interfere. It should not.

The idea is that when the machine is truly heading toward an unusable state, the thing that gets sacrificed first should be the greedy desktop application, not the entire desktop experience.

That kind of prioritization makes sense to me on a personal machine.

Also take note that my config is for KDE Plasma on Wayland, so you may need to adjust it for your own desktop environment.

systemd-oomd is a valid alternative and, in some ways, the more modern one. However, it is more cgroup- and unit-oriented. That makes it better suited to users who want to build memory-pressure policy around slices, scopes, and service units rather than around simple process-name heuristics.

CPU Scheduler: Important, but Usually Not First

This is where I think Linux tuning discussions often get derailed.

People love talking about CPU scheduler tweaks because they feel advanced. They sound like the kind of knobs only power users know about. But in many cases, they are simply not where the real desktop pain is coming from.

If your complaint is that heavy disk I/O makes the mouse stutter, that the desktop becomes sticky when memory pressure rises, or that a large copy causes the UI to hitch, then chances are good that your real problem is not the CPU scheduler.

That does not mean CPU-related tuning is useless. It just means I would rank it below memory and storage tuning for this specific goal.

So my position here is straightforward: do not start with exotic boot parameters just because they sound powerful. If your memory behavior, I/O scheduling, writeback policy, and OOM safety nets are still poor, then CPU scheduler tuning is often just dressing up the wrong layer.

I/O Scheduler: Where Desktop Tuning Becomes Noticeable

If memory handling is one pillar of desktop responsiveness, storage behavior is the other.

This is where I think choosing the right I/O scheduler can actually make a real-world difference, especially on systems that do more than just sit idle and browse light web pages.

For desktop use, I strongly prefer BFQ when it is available.

The reason is not that BFQ is magically the best at everything. It is not. The reason is that BFQ is explicitly biased toward responsiveness and low latency. That is a very desktop-oriented tradeoff. It is willing to give up some throughput in exchange for keeping applications and the UI feeling smoother under competing disk workloads.

That is exactly the kind of tradeoff I want.

By contrast, mq-deadline is still a respectable scheduler, and if BFQ is unavailable, it is often the sensible fallback. But if BFQ is there, I think it deserves serious consideration on a desktop machine.

Especially if your system has spinning disks, mixed storage, virtual machines, large background copies, indexing, package installs, or any kind of workload where background I/O can interfere with foreground smoothness.

So my bias is:

I would much rather lose a bit of benchmark bragging rights than have the desktop visibly stumble every time storage gets busy.

Writeback Tuning: One of the Most Overlooked Causes of Stutter

One thing that surprised me when digging deeper into Linux desktop responsiveness is just how much writeback behavior can affect the feel of the system.

A lot of visible stutter during heavy disk activity is not simply “the disk is busy.” It is that the system allowed too much dirty data to accumulate, and then when the writeback pressure hits, it becomes far more disruptive than it needed to be.

This is why I think writeback tuning is one of the most overlooked areas for desktop systems.

For a desktop, I generally prefer lower and more explicit dirty data limits rather than letting very large bursts accumulate. In practice, that can mean the system starts background flushing sooner and behaves in a steadier, more controlled way.

A practical starting point would be:

				
vm.dirty_background_bytes=268435456
vm.dirty_bytes=1073741824

That is:

This is not some universal law. It is simply a desktop-first preference.

The idea is that I would rather keep writes moving more steadily than allow a huge burst to build up and then pay for it later in the form of visible hitching.

Again, this is the theme of the whole article: less emphasis on peak throughput, more emphasis on graceful behavior.

Graphics Saturation Is a Different Kind of Responsiveness Problem

Up to this point, I have mostly focused on responsiveness problems caused by memory pressure and storage contention. However, those are not the only ways a Linux desktop can become unpleasant under load. Graphics saturation can cause a very similar kind of visible stutter, especially when the same GPU is responsible for both driving the desktop compositor and handling a heavy rendering workload.

In other words, the desktop can become unpleasant not because the machine is out of memory or because the disk is busy, but because the GPU that is responsible for drawing the session is now too busy doing something else.

That is where hybrid graphics become relevant.

Utilizing Integrated GPUs

If your hardware supports it, one practical way to keep the desktop responsive is to let the integrated GPU handle the desktop compositor while offloading heavier applications to the dedicated GPU.

The reason is simple. On Linux, there is no universal, user-facing equivalent to the block I/O schedulers we can switch for storage. The graphics stack does have internal scheduling, and compositors like KWin try to predict frame timing, but when the GPU driving the desktop becomes saturated, the compositor can still miss frame deadlines and the result is visible stutter. KWin’s own explanation of this problem is that once a frame deadline is missed, some frames are shown twice while others are skipped, which is exactly the kind of “my desktop feels like it is freezing even though it technically is not” behavior users notice.

In other words, what is missing on Linux is not GPU scheduling in the absolute sense, but a universal, user-facing desktop-priority policy for graphics. The drivers and compositors do have internal scheduling and frame-timing logic, but there is no simple cross-vendor equivalent to saying “the desktop environment comes first; everything else can fight for what remains.”

That being said, this is where hybrid graphics can help. NVIDIA’s PRIME Render Offload model explicitly treats one GPU as the sink that renders the main desktop, while selected applications can be rendered on another GPU as the source. In practice, this means the integrated GPU can remain responsible for presenting the desktop while the dedicated GPU handles the heavier rendering workload.

For example, if I visit the browser-based GPU stress test and the browser is rendering on the same GPU that is driving my desktop, the whole session can stutter so badly that stopping the test becomes annoying. That site is explicitly designed to heavily load the GPU through WebGL and JavaScript, so this behavior is not surprising.

However, if that heavy application is instead running on the dedicated GPU while the desktop itself remains on the integrated GPU, the application itself may become sluggish, but the desktop often remains usable. In other words, the lag is isolated more to the application instead of dragging the whole session down with it.

This is also not just a laptop thing. Desktop systems can benefit from it too, as long as the CPU has an integrated GPU and the motherboard exposes display outputs for it. In my case, my 12th Gen Intel(R) Core(TM) i7-12700 has an iGPU, and I can use it alongside an NVIDIA 4060 just fine. The catch is that the monitor driving the desktop has to be plugged into the motherboard’s HDMI or DisplayPort output rather than directly into the discrete GPU. If your UEFI also supports an implicit main GPU setting, that can help ensure the integrated GPU remains the one driving the desktop. Once that is in place, the integrated GPU can keep the desktop responsive while the dedicated GPU handles heavier applications.

Desktop Tuning Is About Choosing the Right Tradeoff

I think this is where people sometimes get overly defensive.

The moment you suggest tuning a Linux desktop away from its default behavior, someone will inevitably say that the defaults exist for a reason. And yes, of course they do.

But that does not mean those defaults are optimal for every use case.

A distro has to make decisions that work broadly. A desktop user is allowed to make decisions that work narrowly.

That means accepting tradeoffs honestly:

From my perspective, these are all perfectly reasonable desktop trades.

A personal machine is not a benchmark harness. It is a machine meant to remain usable while you are actually using it.

A Practical Desktop-First Profile

If I were to summarize the direction I would take for a mainstream Linux desktop, it would look like this:

  1. Enable zram with a sane size and high priority
  2. Keep a real swap file instead of relying on zram alone
  3. Use BFQ where available, especially on disks that affect interactivity
  4. Use mq-deadline as the fallback when BFQ is unavailable
  5. Lower dirty writeback thresholds so storage pressure becomes steadier and less bursty
  6. Use earlyoom as a final safety net so one bad process does not ruin the whole session
  7. Treat CPU scheduler tweaks as secondary, not foundational
  8. Use hybrid graphics strategically if GPU-heavy workloads are dragging the whole desktop down

That, to me, is a much more coherent desktop strategy than just randomly piling on boot parameters and hoping one of them feels faster.

Conclusion

Mainstream Linux distributions are not broken, nor are they secretly “server-only” operating systems pretending to be desktops. But I do think many stock, general-purpose distro defaults reflect broader priorities more than desktop-first ones.

There are exceptions. Distros such as CachyOS and Bazzite already ship with more opinionated tuning aimed at responsiveness and gaming. However, the average Fedora, Ubuntu, or Arch installation still tends to favor broad compatibility and conservative defaults over a specifically desktop-tuned behavior under pressure.

And for a lot of users, that difference matters.

A desktop machine should not merely perform well in ideal conditions. It should remain pleasant when things get messy: when memory gets tight, when storage gets hammered, when the browser goes wild, when the GPU gets saturated, or when background workloads refuse to stay politely in the background.

That is why I think desktop Linux often benefits from a more opinionated tuning profile.

For me, that profile begins with zram, a real swap file, a responsiveness-oriented I/O scheduler like BFQ, tighter writeback behavior, and a safety valve like earlyoom. If graphics saturation is also a problem, then hybrid graphics can be another practical tool for keeping the desktop usable under load. Only after those are in place do I think it makes sense to worry much about more exotic scheduler or kernel-parameter tweaks.

In other words, I am not trying to optimize Linux for theoretical maximum performance.

I am trying to optimize it for what I actually want from a desktop: responsiveness, graceful degradation, and a machine that still feels like it belongs to me even when it is under pressure.

That, to me, is the more practical goal.

~ End ~

There are 121 viewers that have read this page.

Fediverse

Boosts0
Favorites0

Reply to this post on Mastodon

Bluesky

Reposts0
Likes0

Reply to this post on Bluesky

richardorilla
Richard Orilla :mastodon: @richardorillaFediverse
Apr 3, 2026Boosts: 0 · Faves: 0

@nwcs Hahaha, I'm so used to clean install that I do it everytime I upgrade. Thankfully Flatpak and my VMs help alot from recovering.

nwcs
NWCS @nwcsFediverse
Apr 3, 2026Boosts: 0 · Faves: 0

@richardorilla I'm on at least 3 Linux Mint upgrades. Waiting for the upgrade that forces a clean install.

Go back to top

Go back to list of articles