Not in focus GUI window causes high CPU utilization

[Hoffs]

Environment

Windows build number: Microsoft Windows [Version 10.0.21387.1]
Your Distribution version: Ubuntu 20.04
Your WSLg version: 
WSLg ( x86_64 ): 1.0.22+Branch.main.Sha.d7102a7ff8a3bb04bbcd3483c3f7d7a7633686a1
Mariner: VERSION="1.0.20210224"
FreeRDP: 5f083fa0b97d433d6204985f6047886e29c1c61e
weston: 9e402088aa2cd9316851ea20b9befbcf3b9c9564
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5
mesa:

Steps to reproduce

• Start ubuntu distro
• Install xterm
• Start xterm (doesnt matter if using desktop icon or from within terminal)
• Click to focus the terminal
• Click to focus any other window
• Observe Vmmem CPU usage jump

I observed same behavior in Debian + Alacritty/st and Ubuntu + Xterm. On my machine usage jumps from ~0% to ~12%. Once the window is focused again the usage drops to ~0% again.

I also tried changing refresh rate from 144 to 60, but the cpu usage remains the same.

Expected behavior

No apparent CPU usage increase when not in focus.

Actual behavior

Higher CPU usage when out of focus compared to in focus.

When xterm window is focused:

When task manager is focused (snipping tool forces it to lose focus when capturing the image but the point remains the same)

[onomatopellan]

Same issue here. When a wayland or x11 app is not in focus or is minimized my CPU usage jumps to 25%. At that point using top from inside the systemdistro you can see the weston process using almost the 100% of one core from the six of my i5-9400F. Attaching weston process to strace shows these lines repeatedly until it gets the focus again and CPU drops to 0,1%:

epoll_wait(5, [{EPOLLIN, {u32=2228879200, u64=94899531284320}}], 32, -1) = 1
recvfrom(27, 0x564f84da0230, 2, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(75, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)

specs

Windows build number: Microsoft Windows [Version 10.0.21390.1]
Your Distribution version: Ubuntu 21.04
Your WSLg version:
WSLg ( x86_64 ): 1.0.22+Branch.main.Sha.d7102a7ff8a3bb04bbcd3483c3f7d7a7633686a1
Mariner: VERSION="1.0.20210224"
FreeRDP: 5f083fa0b97d433d6204985f6047886e29c1c61e
weston: 9e402088aa2cd9316851ea20b9befbcf3b9c9564
pulseaudio: 2f0f0b8c3872780f15e275fc12899f4564f01bd5
mesa:

Edit: Workaround: just hover the mouse cursor over the Minimize, Maximize, Close buttons of an unfocused window, the weston process goes to sleep and stops consuming CPU even if the app is not in focus.

[onomatopellan]

@hideyukn88 Were you able to repro this? After testing every WSLg version released I found this issue happens since WSLg 1.0.21. It looks like something from this commit is making increase indefinitely the CPU power usage when a linux app like xterm is not focused.

[hideyukn88]

@onomatopellan , yes, I am able to repro this issue, but it's not by focusing away from xterm window. The way I can repro is by minimizing xterm window, then CPU usage of weston reach 100% in top. I can spend sometime later day to take a look. thanks!

[m-7761]

FWIW (not interesting) what I saw with a fresh install last week was identical to how it's described. (I.e. once it kicks in, it goes up to ~10% or less until the mouse hovers back over the inactive window. Then it seems to go away.)

[hideyukn88]

(memo to myself) somehow file descriptor from FreeRDP's dynamic virtual channel message queue stay readable, thus Wayland display loop keep awake and calling RDP-backend to see any outstanding job, but since that message queue is empty, nothing done. WinPR's MessageQueue_Peek doesn't not reset (= read) fd if queue size is zero, thus fd stay readable. The possibility is some code is making that readable without actually queueing message.

Update: issue is now understood.

[onomatopellan]

I can confirm this issue is fixed with latest weston commit. Thanks a lot!

[thangamani-arun]

this happens, after wakeup from hibernation. So be aware of it. It happens to you, just read here: microsoft/WSL#6982 (comment)

[hideyukn88]

@thangamani-arun, would you please share log files from /mnt/wslg while this is happening? thanks!

[thangamani-arun]

@hideyukn88 san: here are the logs, but I don't have the issue now. Idon't see any cpu usage at this moment.

pulseaudio.log
stderr.log
weston.log
wlog.log

[hideyukn88]

@thangamani-arun, thanks for quick response, but I don't see any clue other than below message logged in weston.log. Does this log continue to grow with these messages? thanks!

[18:49:13.998] xfixes selection notify event: owner 2097153
[18:49:13.998] our window, skipping
[18:49:14.863] xfixes selection notify event: owner 2097153
[18:49:14.863] our window, skipping
[18:49:40.124] xfixes selection notify event: owner 2097153
[18:49:40.124] our window, skipping
[18:50:23.488] xfixes selection notify event: owner 2097153

[thangamani-arun]

@hideyukn88 : I'm not sure. but as far as I remembers, When I try to launch Ubuntu-20.04 wsl app, It was keep blinking nothing was happening and it was hung and CPU usage was high. Then after some research I was able to kill and re-launched it without hanging issue.

FYI. I was not able to shutdown the wsl from cmd.exe, the command was infinitely waiting. Hence I had to use hcsdiag kill to kill and able to relaunch it.

[hideyukn88]

@thangamani-arun, thanks for info, if it happens again, please take a log following the steps at https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#8-collect-wsl-logs-recommended-method, and share with us, thanks!