Package is installed from It's basically unusable. Each new tab and new line of output adds iowait. There is a plenty of RAM available. No disk usage. strace also shows no any weird behaviour. |
Replies: 23 comments 59 replies
|
Discussion until we can debug and extract some actionable info. We have a lot of arch users. |
|
This solution is not working for me. Ubuntu 24.04 6.8.0-51-generic. Rebuilt as above, and am still seeing high wa in top Ghostty 1.0.0 Version
|
|
chiming in to confirm that building against epoll worked for me on kernel 6.8: |
|
@alslater there are two users for whom the solution worked well on Ubuntu 24.04 with kernel version 6.8.0-51. You can try grep -R 'const xev = @import("xev"' .
./src/cli/version.zig:const xev = @import("xev").Epoll;
./src/os/cf_release_thread.zig:const xev = @import("xev").Epoll;
./src/renderer/Metal.zig:const xev = @import("xev").Epoll;
./src/renderer/Thread.zig:const xev = @import("xev").Epoll;
./src/termio/backend.zig:const xev = @import("xev").Epoll;
./src/termio/Exec.zig:const xev = @import("xev").Epoll;
./src/termio/mailbox.zig:const xev = @import("xev").Epoll;
./src/termio/Options.zig:const xev = @import("xev").Epoll;
./src/termio/stream_handler.zig:const xev = @import("xev").Epoll;
./src/termio/Termio.zig:const xev = @import("xev").Epoll;
./src/termio/Thread.zig:const xev = @import("xev").Epoll;
./src/global.zig:const xev = @import("xev").Epoll;
./src/main_ghostty.zig:const xev = @import("xev").Epoll;All those files must have the content as shown, using Epoll. After that you must compile. |
|
@plinkr Hmm. OK, my bad. It seems that I must have still had a ghostty window opened somewhere when I recompiled/reinstalled, I use gtk-single-instance = true. After actually killing all windows and restarting, the issue is fixed. |
|
Arch user here (Cinnamon desktop, 6.12.7 kernel), can confirm that the epoll fix here works. I can also confirm that without it, |
|
I'm also on Arch (Plasma 6.2.4, Linux-LTS 6.6.67, Intel Kabylake GPU) and seeing high iowait. It goes up by about 23 at first launch and then an extra 13 for every tab launched. Curiously, I was first alerted because Plasma's System Monitor was showing 100% Total Usage on two cores, increasing by an extra two cores for roughly every two tabs. Turns out that figure includes iowait. |
|
Quick update - I've just tested on the following:
All have the same issue (I used |
|
I'm experiencing the same cpu hogging on Ubuntu 24.04, using kernel 6.8.0-51-generic CPU: 11th Gen Intel(R) Core(TM) i7-1185G7 |
|
I can also report this issue on amd64 Gentoo CPU: 12th Gen Intel(R) Core(TM) i7-1260P |
|
Most of the time I only use one instance of Ghostty since I use tmux, but I just checked for that exact problem after seeing that discussion and it looks like it is here. Though I don't think I would have seen that problem if I hadn't known before... |
|
I can also report the same issue on Manjaro under Plasma 6.2.4-1, with kernel 6.6.65-1-MANJARO |
|
@plinkr's solution above works for me too. |
|
Add me as well. I didn't find this thread because it seemed to be labelled as Arch and Intel, and here I am on Ubuntu with a Ryzen 7840u system... Kernel 6.8.0, custom ghostty build > 1.0.1 build to test a fix for #4605. Noticed the high wait times the last week on my system, but no slowdowns, or fan noise, or battery issues. But changing this code brings my CPU idle right back to 99% with 0% waits, and it reassures my head a bit 😉. |
The PR in libxev has waitid feature, but not merged, you can try it, the PR you mention doesnot relate this issue |
|
I did not say it was... |
|
Same on Arch with hardened kernel |
|
related: axboe/liburing#943 |
|
Great find |
|
I have this issue on nixos how can I implement @plinkr 's solution? |
|
This has solved it. Thank you very much @qubitnano |
|
love it! but how can I make it an overlay and not a package? or is that impossible? |
Yes you can also set ghostty to that override in an overlay as well to just set ghostty in your packages. |
|
oh btw with the newest ghostty update I have to do (old.preBuild or ""...) is this bad? |
I have had to change to I was getting an extremely unhelpful error message too: |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Same here on NixOS using the official flake. Rev:
|
|
I read source code libxev, Epoll uses single thread, io_uring uses multi threads. When ghostty starts, it holds io_exec - shell. and when io_uring is coming, per tab will handle per io_exec per thread while EPoll only triggers event for specific thread's event. Then it's not kernel issue. |
|
Seeing the same behavior on Arch using latest ghostty build via AUR, but on AMD iGPU. |
|
I can confirm that on my machine the solution using epoll solves the issue. My specs from fastfetch: When I run the version installed via my package manager, some tools report 10-15% more CPU usage for each instance of Ghostty running, but after |
|
Unfortunately, reproducing the above does not resolve the problem for me. My fastfetch output: I replicated @ForeverZer0's steps, with the exception that I installed After running the resulting binary,
The |
|
It very well may be a different problem altogether, but just to rule it out, I noticed from your config that you are using bash, and wanted to confirm that you have As @plinkr pointed out, you can confirm this by running the following Output (your order may differ): |
|
You're a champ. I set |
|
Just wanna chime in and say that I'm also experiencing high iowait times on Fedora 41 with KDE Plasma 6.2.5, Linux 6.11.11, which unfortunately messes up my hardware monitoring metrics. Was using 1.0.1 built from copr repo. Using plinkr's solution (thank you <3 ), building with epoll, has fixed the issue for me! Build info: |
|
I do not know how to analyse it, but slower than alacritty and kitty is obvise. I use the arch alph v4 version |
|
@mitchellh Anything we can do to help? I'm running Arch on both Intel and AMD, with the same problem. |
|
see #3224 (comment) |
|
Thanks. As I read it, it seems unresolved and undecided whether it's a bug. |
|
fix coming into kde cpu monitor plugin that solves the only issue I had with it. maybe everyone else should also simply ignore iowait? is it actually a useful stat? |
|
Yep. It's nice to see if something thrashing storage. It's quite informative in personal and infra contexts. |
|
Using the stock package (currently 1.1.2-1) on Arch, I see very high CPU usage in |
|
Also experiencing this behavior. I wonder if it's different than the high-iowait iouring/epoll problem? Scrolling in vim spikes CPU (haven't determined if iowait or other), and hugely lags. Also removing focus from a ghostty window that has vim running, and then refocusing that window and performing any move operation (e.g. hjkl or scroll) stalls for almost 60s. Not sure if related to the other issues here, and I haven't tested the epoll solution yet |
The version of ghostty that is in the Arch repo at the time of writing is 1.1.2, and it has the high iowait issue. Additionally, it does not support the configuration to change the backend described here. I recommend that you try recompiling ghostty to the current version and use the configuration to switch to the epoll backend to see if you still encounter the same problem. |
|
I've compiled from the most recent commit ( For general usage, at idle, etc. I do see iowait dropping. Confirming the same as the rest of the experiences in this thread. My vim + scrolling problem remains, however. And it seems specifically limited to mouse scrollwheel usage. not related to this discussion. I will see where else that debugging conversation belongs |
|
After the commit d532a6e, you can configure the async-backend to use whichever one you prefer. If you experience issues with high iowait, you can configure and restart it afterwards. You no longer need to recompile. |
|
I confirm that it works for me on Archlinux. I would normally use the epoll fix. I rebuilt from source without the fix, added the config line and now iowait is on par with other terminals. Thank you! |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Strange thing. I'm on version 1.1.3 and it seems that this configuration option does not exists. It also missing on the docs website: https://ghostty.org/docs/config/reference. Is it some other special config? Update: looks like this option was not included in 1.1.3 :( |
|
This is part of the tip builds (1.2.x) and has not been backported to 1.1.3. |
|
I want to be clear that it won't be backported to 1.1.x either. The changes required to make it work are far too risky for a back port and I don't consider this issue a bug (its a reporting issue at best and a scheduling bug at worst but in either case its the kernel's problem, not mine). |
|
More context: The trouble with iowait [LWN.net] |
|
I installed ghostty last week for the first time and was mystified when I later discovered all of my CPUs were at 99% iowait at all times. Once I found this post and changed async-backend to epoll I stopped having this problem. I feel like this should be noted in the documentation rather than in a discussion because it was quite frustrating trying to identity where this iowait was coming from. I will note that for anyone using hyprland, leaving this settings on auto (resulting in uring) eventually caused all of my ghostty windows to trigger ANR and it was forced to terminate them all or have them entirely freeze permanently if I chose 'wait' instead. |
|
Would using IORING_ENTER_NO_IOWAIT still alloy for the features of uring without generating high iowait times? |
|
That's something to discuss in the upstream libxev repo. |
|
Chimming in to confirm that after debugging this for days on CachyOS machine, I have accidentally tried booting into X11/openbox with xterm to have IOWAIT disappear. Setting appears to fully resolve the problem. I do not however agree, that it is just a reporting problem, because I had experienced general system lockups and freezes/stalls. |
This comment was marked as off-topic.
This comment was marked as off-topic.
and others
After the commit d532a6e, you can configure the async-backend to use whichever one you prefer. If you experience issues with high iowait, you can configure
ghosttylike this:and restart it afterwards. You no longer need to recompile.