Updated: July 4, 2025
I love me a good mystery. Although I'm not happy and I'm rather worried about the direction the Linux home desktop is going, AKA forced deprecation of X11 before its would-be successor Wayland is truly ready, there's some small joy in telling a good story, replete with numbers. Indeed, after I published my Plasma 6.4 review, which showed Wayland being less optimized even for truly basic stuff, I decided to dig in and expand more on that early test and its troubling findings.
A few days back, I published some GPU benchmarks, very rudimentary, Wayland vs X11 in Plasma 6.4. I did it on the same test box, with its integrated AMD graphics, using the radeontop utility. The results explains why you may expect to see GPU spikes with Wayland, simply because it is less optimized, less efficient than the X11 session. Now, I want to back those numbers up with additional data, namely CPU and power figures.
Power utilization
We talked about GPU stuff, now let's talk battery drainage. I used powertop, a tool that we've seen before, in my TLP tutorial from quite a while back. You can use this utility interactively, or let it save data to csv files, from which you can then derive various statistics.
With System Monitor running, as in the previous examples, I launched powertop in a Konsole window, and saved 3x5 measures (each over 20 seconds, by default) for each one of the scenarios, Wayland with power efficiency and color accuracy, respectively, plus the X11 session. There were no other programs running, and I didn't even move the mouse cursor. Pretty idle desktop, if you will.
Mini disclaimer: battery usage depends on tons of factors, including battery health and temperature. Short power tests are not too accurate, so please take this into account. Then again, I'm not trying to do any mega research here, I just want to present you with some rather interesting numbers. But, if you take into account all of the stuff I've shown you so far, plus some CPU data (see below), you will see a rather clear, unequivocal trend.
| Metric | Wayland +
power efficiency |
Wayland +
color accuracy |
X11 session |
| Battery drain (W) | 6.09 | 6.05-6.08 | 5.67-5.87 |
The table shows the "range" of average battery usage for each of the 3x5 measurements. The Wayland power efficiency mode was consistent, with no fluctuations. The Wayland color accuracy mode registered just a tad over 6 W of battery drain. The X11 session reported 5.67 W in the best case and 5.87 W in the worst case.
It make sense that there would be almost no difference between the two Wayland modes. Since I didn't really run any graphics tasks, the difference in the selected mode shouldn't affect the power drain, other than what the desktop does on its own.
As an aside, in each of the measurements, for all sessions, the first of the five samples in each set would always register the highest usage, slowly tapering. I'm not 100% sure what algorithms powertop uses, but the power function may be similar to the load function used in a tool like top.
For example, from a Wayland color accuracy mode run:
The battery reports a discharge rate of: 6.38 W;
The battery reports a discharge rate of: 6.16 W;
The battery reports a discharge rate of: 6.02 W;
The battery reports a discharge rate of: 5.88 W;
The battery reports a discharge rate of: 5.79 W;
If I compare the different sessions, then in the worst case, X11 uses 3% less battery juice than Wayland in the most favorable scenario for Wayland, or 7% less in the least favorable scenario. However, I'm already telling you, these results are not 100% representative. But they are indicative.
Idle desktop, CPU figures
Now, one could possibly say that the System Monitor is to blame, but the thing is, no matter what you choose, you can always shift the blame from Wayland to everything else. The simple truth of the matter is, X11 simply works better, in the vast majority of cases. This includes raw performance.
To wit, I did the following test: I launched a fresh session, I opened Konsole and ran vmstat, an old, trusty tool that we discussed thoroughly in the past. Basically, this means you get the pure desktop session plus just a single command-line window. Nothing more, nothing less. No tomfoolery.
I waited for any background tasks that may kick in early in the session to settle, and then ran vmstat in a loop, 60 iterations with a 1s interval between them. I collected the data and looked at various interesting averages.
vmstat 1 60
And this is the table with the averaged values:
| Metric | Wayland +
power efficiency |
Wayland +
color accuracy |
X11 session |
| Average no. of tasks in the runqueue | 0.18 | 0.35 | 0.07 |
| Total tasks in the runqueue | 11 | 21 | 4 |
| Interrupts (in) | 1188 | 1173 | 937 |
| Context switches (cs) | 1195 | 1208 | 803 |
| Idle CPU % (id) | 98.03 | 97.90 | 98.17 |
From here, we can see that the X11 session used 1.83% CPU while idle, whereas Wayland used 1.97% with the power efficiency mode and 2.1% with the color accuracy mode. This doesn't sound like a "big" difference, but then again, it aligns with the power figures, GPU figures, and everything else. And remember, the more load you induce on the system, the bigger and more meaningful the deltas are.
Effectively, the color accuracy mode was 14% hungrier than the X11 session, while the power efficiency one was 7.6% hungrier. This aligns with the earlier power measurements.
And it makes sense, because the Wayland sessions did far more interrupts and context switches than the X11 session. More access to hardware, more switches between tasks. Now, for an interactive session like the common desktop, you actually do want more context switches, because that means reduced latency, all other things being equal, but then, if you also have more interrupts, you might lose any potential benefits by accessing hardware. And this is apparent in the number of tasks that vmstat registered in the r column (runnable queue). For whatever reason, the Wayland sessions triggered more tasks, 3-5x more. Again, these are seemingly tiny figures, but they do add up over time.
In terms of interrupts and context switches, Wayland executed at least 25% more interrupts and 48% more context switches in the best case. Now, this does not linearly translate into same-percentage performance lags, but it is, once again, indicative.
Rudimentary kernel profiling
Let's see what happens under the hood, shall we. To this end, I decided to use the perf utility, which lets you examine the calls in the kernel, the CPU behavior and whatnot. We shall have two tests here. One, perf record and perf report with System Monitor running, to see what happens while this specific program is "active", as it's the one I used when I noticed the 100% GPU utilization problem in Wayland. Two, an empty desktop with just a Konsole window open, and perf stat running, collecting statistics. Both runs, one minute duration, for each of the three scenarios.
For those curious, this is what the System Monitor CPU and GPU graphs show for a regular (Wayland) desktop session, a mostly idle desktop for the first 30 seconds or so, and then with some windows opening and closing, some windows being minimized, mouse cursor movement, and such:
Once again, notice the wonky borders in System Monitor, but okay.
Anyway, perf record, followed by perf report, with top 15 calls shown, Wayland power efficiency mode:
Samples: 72K of event 'cycles:P', Event count (approx.): 17887149286
Overhead Command Shared
Object Symbol
11,67% ksgrd_network_h
[kernel.kallsyms] [k] inet_diag_du
8,64% swapper
[kernel.kallsyms] [k] acpi_process
8,40% swapper
[kernel.kallsyms] [k] read_hpet
7,19% swapper
[kernel.kallsyms] [k] io_idle
1,28% plasma-systemmo
libQt6Core.so.6.9.0 [.] QCoreApplica
0,95% kwin_wayland
[kernel.kallsyms] [k] read_hpet
0,81% plasmashell
[kernel.kallsyms] [k] read_hpet
0,77% swapper
[kernel.kallsyms] [k] amdgpu_devic
0,55% swapper
[kernel.kallsyms] [k] srso_safe_re
0,51% plasma-systemmo
[kernel.kallsyms] [k] read_hpet
0,49% plasmashell
libQt6Core.so.6.9.0 [.] QCoreApplica
0,47% swapper
[kernel.kallsyms] [k] menu_select
0,42% swapper
[kernel.kallsyms] [k] psi_group_ch
0,38% swapper
[kernel.kallsyms] [k] native_sched
0,37% swapper
[kernel.kallsyms] [k] __update_blo
...
Wayland color accuracy mode:
Samples: 73K of event 'cycles:P', Event count (approx.): 18916965768
Overhead Command Shared
Object Symbol
11,16% ksgrd_network_h
[kernel.kallsyms] [k] inet_diag_du
8,53% swapper
[kernel.kallsyms] [k] read_hpet
8,25% swapper
[kernel.kallsyms] [k] acpi_process
7,09% swapper
[kernel.kallsyms] [k] io_idle
1,23% plasma-systemmo
libQt6Core.so.6.9.0 [.] QCoreApplica
1,01% kwin_wayland
[kernel.kallsyms] [k] read_hpet
0,76% plasmashell
[kernel.kallsyms] [k] read_hpet
0,65% swapper
[kernel.kallsyms] [k] amdgpu_devic
0,57% swapper
[kernel.kallsyms] [k] srso_safe_re
0,51% plasma-systemmo
[kernel.kallsyms] [k] read_hpet
0,50% plasmashell
libQt6Core.so.6.9.0 [.] QCoreApplica
0,47% kwin_wayland
[kernel.kallsyms] [k] amdgpu_devic
0,47% swapper
[kernel.kallsyms] [k] menu_select
0,44% swapper
[kernel.kallsyms] [k] psi_group_ch
0,40% swapper
[kernel.kallsyms] [k] native_sched
...
X11 session:
Samples: 78K of event 'cycles:P', Event count (approx.): 15670264023
Overhead Command Shared
Object Symbol
13,00% ksgrd_network_h
[kernel.kallsyms] [k] inet_diag_du
9,13% swapper
[kernel.kallsyms] [k] read_hpet
8,45% swapper
[kernel.kallsyms] [k] io_idle
6,56% swapper
[kernel.kallsyms] [k] acpi_process
0,89% plasma-systemmo
libQt6Core.so.6.9.0 [.] QCoreApplica
0,69% swapper
[kernel.kallsyms] [k] srso_safe_re
0,65% swapper
[kernel.kallsyms] [k] amdgpu_devic
0,54% swapper
[kernel.kallsyms] [k] menu_select
0,47% plasma-systemmo
[kernel.kallsyms] [k] read_hpet
0,44% kwin_x11
[kernel.kallsyms] [k] read_hpet
0,41%
Xorg
[kernel.kallsyms] [k] read_hpet
0,39% swapper
[kernel.kallsyms] [k] __update_blo
0,37% swapper
[kernel.kallsyms] [k] native_sched
0,36% swapper
[kernel.kallsyms] [k] update_load_
0,36% swapper
[kernel.kallsyms] [k] psi_group_ch
...
Before we analyze the numbers, let me explain the data:
- The report always shows 100% of whatever was collected, be it 100 samples or 100M samples. Therefore, without knowing what was executed, you cannot compare two different runs. Similarly, you cannot compare percentages. 10% utilization by a function in one run and 10% utilization by the same function in a second run do not necessarily mean the same thing. Or, if one function has 30% use one time and 10% use another time, this does not translate into 3x difference. For that matter, the absolute processor time for the relevant function may be smaller in the run with the "higher" percentage, but in the specific run, it takes a greater proportion compared to the other functions executed.
- That said, since I did the exact same thing for all three scenarios, and all three runs registered in the order of about 20B events and about 75K samples, we can do some comparison among them.
Now, let's look at the numbers and see what the desktop does on idle:
The differences among the sessions are not major, but not insignificant either. The two Wayland modes are almost identical. With X11, a KSysGuard (System Plasma Monitor) network call used more CPU time, however the monitor's libQt6Core library used more processor time in the Wayland session (roughly 1.25% versus 0.9%).
Please note, this is neither good nor bad! The fact a function utilized say 11% or 13% of total CPU time means nothing. We don't know the actual absolute time from the data above. Nor do we know if the specific function is optimized or not, or if the calling program does its job well. After all, something has to take CPU time. It is possible the network calls made by System Monitor can be improved, but that's a separate topic.
KWin_wayland utilized ~1% or ~1.5% time, whereas KWin_X11 used ~0.44% relative share in its run. Plasma Shell as a function does not feature in the top 15 calls for X11, but Xorg is there with 0.41% time. For Wayland, Plasma Shell utilized about 1.3% processor time.
Explicit calls to the GPU, Wayland used 0.77% or a bit more over 1% time (but some of the calls were done through KWin), whereas in the X11 session, the amdgpu call was about 0.65%. So yes, the changes are small, but relatively, they are meaningful, as it would seem the Wayland session was triggering a bit more kernel work.
To wit, let's look at the other test. Idle desktop statistics!
Indeed, on an idle desktop, with just a Konsole window open, a sample perf stat run looks like this:
Performance counter stats for 'system wide':
543.003,88 msec
cpu-clock
# 8,000 CPUs utilized
14.415
context-switches # 26,547 /sec
72
cpu-migrations #
0,133 /sec
201
page-faults
# 0,370 /sec
3.944.748.557
cycles
# 0,007 GHz
452.495.551 stalled-cycles-frontend
# 11,47% frontend cycles idle
1.421.785.350 stalled-cycles-backend
# 36,04% backend cycles idle
...
Transposed into a table, we have the following:
| Metric | Wayland +
power efficiency |
Wayland +
color accuracy |
X11 session |
| CPU clock (ms) | ~543,000 | ~540,000 | ~527,000 |
| Context switches | 14,415 | 26.547/s | 16,120 | 29.864/s | 6,021 | 11.436/s |
| CPU migrations | 72 | 0.133/s | 139 | 0.258/s | 92 | 0.175/s |
| Page faults | 201 | 0.37/s | 450 | 0.834/s | 75 | 0.142/s |
| Cycles | 3.95B | 0.007 GHz | 4.43B | 0.008 GHz | 1.9B | 0.004 GHz |
| Stalled cycles frontend | 452.5M | 11.47% | 616.5M | 13.92% | 213M | 11.13% |
| Stalled cycles backend | 1.42B | 36.04% | 1.45B | 32.82% | 618M | 32.28% |
| Instructions | 780M | 0.2/cycle
1.82 stalled/cycle |
901M | 0.2/cycle
1.61 stalled/cycle |
483M | 0.25/cycle
1.28 stalled/cycle |
| Branches | 168M | 309K/s | 193M | 358K/s | 104M | 197K/s |
| Branch misses | 13.83% | 13.36% | 11.7% |
So what do we have here? Lots and lots of cool stuff. TL;DR: The X11 session is simply leaner!
It used less CPU clock time, used about half the cycles and instructions that Wayland did, it had fewer stalled cycles, fewer page faults and context switches, even fewer branch misses. Even when the system does really minimal work, you can expect the crummy old X11 to be ever so slightly more frugal.
And enough numbers for one article, don't you think?
Conclusion
Now, I could keep on benchmarking and benchmarking. I could also throw in other devices into the mix, with Intel graphics, Nvidia graphics, hybrid graphics, and then some. Except, I have only so much free time and so much appreciation for a good mystery. I could also tell you that I'm pretty certain, without having conducted any additional benchmarks, that whatever you see in Plasma, this is probably better than what you'll see in other Wayland and X11 sessions in other desktop environments. After all, my Plasma 6.4 review findings very nicely and predictably align with years and years of testing.
Does these results point to any cardinal showstopper bug in KWin or Wayland or anything else, something that would explain the 100% GPU spikes? Alas, not. In fact, the more I test, the more I realize that the suboptimal numbers are a result of suboptimal software, not anything broken in the hardware or the drivers. I am quite sure no developer out there uses a lowly 2019 laptop for their work. Most probably have 32-core top-of-the-line systems, and so what may look like rounding errors on blistering-fast monster rigs is actually badly optimized (Wayland) code. But we can't blame just Wayland. Most modern software is badly optimized. There's frivolous use of system resources, as if money grows on trees and everyone's a rich Californian who can buy expensive hardware every couple of years.
Once again, what I'm showing here is a troubling trend. "Heavy" code that will make Linux run badly on older systems, or at least, not as good as they could run. MX Linux is the best example of spartan, a proof that it can be done. Wayland not being stable enough. Wayland not being as fast as X11. Arbitrary decisions that force the user's hand. All of these are manifestations of a self-defeating pattern that is slowly spreading through the Linux world. And it will, without any help from Microsoft and alike, reduce the chances of the Linux desktop actually becoming a sound, healthy alternative to Windows. So, keep X11 around. Not for my sake. Not for us grumpy dinosaurs. For the sake of the Linux desktop future. Bye bye now, fellow nerds.
Cheers.