wslg: High CPU load (Virtual Machine Worker Process + System) when session is IDLE

Version

Win: 10.0.22622.575 WSL: 0.66.2.0 Kernel: 5.15.57.1

WSL Version

WSL 2
WSL 1

Kernel Version

5.15.57.1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

Install WSL2/Ubuntu and start a session. Obeserve in Windows Task manager high load on both “Virtual Machine Worker Process” and “System”. Both taking 15% CPU each for a combined 30+% CPU load. After wsl --shutdown the issue is gone.

Expected Behavior

No significant CPU usage when Linux/WSL is IDLE.

Actual Behavior

This is on my Surface Pro X (aarch64) - other ARM machine users for instance with the new Thinkpad X13S have reported similar obervations.

Both “Virtual Machine Worker Process” and “System”. Each taking roughly 15% CPU for a combined 30% CPU load.

Linux System is idle:

wsl --system -d Ubuntu Top

PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND 1 root 20 0 2.1m 1.5m 0.0 0.0 0:00.02 S /init 2 root 20 0 2.2m 1.6m 0.0 0.0 0:00.01 S - /init 27 root 20 0 2.3m 0.1m 0.0 0.0 0:00.00 S - /init 28 root 20 0 2.3m 0.1m 0.0 0.0 0:00.07 S - /init 30 wslg 20 0 9.5m 4.4m 0.0 0.1 0:00.09 S - -bash 7 root 20 0 2.1m 0.2m 0.0 0.0 0:00.00 S - /init 8 root 20 0 45.9m 7.3m 0.0 0.1 0:00.01 S - /usr/bin/WSLGd 11 wslg 20 0 674.9m 34.3m 0.0 0.4 0:00.55 S - /usr/bin/weston --backend=rdp-backend.so --modules=wslgd-notify.so --xwa+ 15 wslg 20 0 18.5m 7.2m 0.0 0.1 0:00.03 S - /usr/libexec/weston-rdprail-shell 31 wslg 20 0 44.7m 17.7m 0.0 0.2 0:00.04 S - /usr/bin/Xwayland :0 -rootless -core -listen 37 -wm 38 -terminate -n+ 16 wslg 20 0 2.0m 1.5m 0.0 0.0 0:00.00 S - /init /mnt/c/Program Files/WindowsApps/MicrosoftCorporationII.WindowsSub+ 17 message+ 20 0 7.8m 3.3m 0.0 0.0 0:00.02 S - /usr/bin/dbus-daemon --syslog --nofork --nopidfile --system 18 wslg 20 0 230.1m 7.2m 0.0 0.1 0:00.06 S - /usr/bin/pulseaudio --log-target=file:/mnt/wslg/pulseaudio.log --load=mo+ 22 wslg 20 0 7.6m 0.3m 0.0 0.0 0:00.00 S - /usr/bin/dbus-daemon --syslog --fork --print-pid 6 --print-address 8 --session 93 root 20 0 2.1m 0.1m 0.0 0.0 0:00.00 S - /init 94 root 20 0 2.1m 0.1m 0.0 0.0 0:00.00 S - /init 95 wslg 20 0 6.4m 2.1m 0.0 0.0 0:00.02 R - top

Diagnostic Logs

WslLogs-2022-08-24_17-14-22.zip

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 26 (6 by maintainers)

Most upvoted comments

Is there deployment ETA for the normal Win 11 build? Still an issue on Pro X.

leuler27 on Oct 25, 2022

Seems to have been fixed!

Edition	Windows 11 Pro
Version	22H2
OS build	22621.900

MdeRhoter on Dec 6, 2022

Now we understood the issue and the fix is being made. The fix will be at Windows OS side (not WSL/WSLg), thus ETA for fix is still unknown, once I know more, will post here, thanks!

hideyukn88 on Sep 15, 2022

Issue still present! “guiApplications=false” doesn’t help

dtgeorge on Sep 12, 2022

Same here on a Surface Pro X SQ1/16GB, running Windows 11 22H2

martijnd@SurfX:~$ uptime 19:57:35 up 0 min, 0 users, load average: 0.00, 0.00, 0.00

PS C:\Users\mderh> wsl --shutdown

MdeRhoter on Aug 25, 2022

From the trace it looks like Weston is crashing (probably repeatedly). Moving this to the WSLg repo so they can take a look.

47 | [ 3669.878869] rcu: INFO: rcu_sched self-detected stall on CPU
48 | [ 3669.880104] rcu: 	7-....: (284690 ticks this GP) idle=2b5/1/0x4000000000000002 softirq=6722/6722 fqs=139933
49 | [ 3669.881777] 	(t=285022 jiffies g=13973 q=9751)
50 | [ 3669.882640] Task dump for CPU 7:
51 | [ 3669.883222] task:weston          state:R  running task     stack:    0 pid:  285 ppid:   231 flags:0x0000000a
52 | [ 3669.884788] Call trace:
53 | [ 3669.885147]  dump_backtrace+0x0/0x1c8
54 | [ 3669.885739]  show_stack+0x1c/0x28
55 | [ 3669.886367]  sched_show_task+0x14c/0x180
56 | [ 3669.887002]  dump_cpu_task+0x48/0x54
57 | [ 3669.887617]  rcu_dump_cpu_stacks+0xf4/0x138
58 | [ 3669.888150]  rcu_sched_clock_irq+0x938/0xaa0
59 | [ 3669.888982]  update_process_times+0x9c/0x2e0
60 | [ 3669.889895]  tick_sched_handle.isra.0+0x38/0x50
61 | [ 3669.890750]  tick_sched_timer+0x50/0xa0
62 | [ 3669.891338]  __hrtimer_run_queues+0x11c/0x328
63 | [ 3669.892125]  hrtimer_interrupt+0x118/0x300
64 | [ 3669.892710]  hv_stimer0_isr+0x28/0x30
65 | [ 3669.893245]  hv_stimer0_percpu_isr+0x14/0x20
66 | [ 3669.894180]  handle_percpu_devid_irq+0x8c/0x1c0
67 | [ 3669.895011]  handle_domain_irq+0x64/0x90
68 | [ 3669.895608]  gic_handle_irq+0xb8/0x128
69 | [ 3669.896201]  call_on_irq_stack+0x28/0x3c
70 | [ 3669.896783]  do_interrupt_handler+0x54/0x5c
71 | [ 3669.897423]  el1_interrupt+0x2c/0x40
72 | [ 3669.897951]  el1h_64_irq_handler+0x14/0x20
73 | [ 3669.898524]  el1h_64_irq+0x74/0x78
74 | [ 3669.899177]  clear_rseq_cs.isra.0+0x4c/0x60
75 | [ 3669.899746]  do_notify_resume+0xfc/0x3c0
76 | [ 3669.900320]  el0_svc+0x3c/0x48
77 | [ 3669.900915]  el0t_64_sync_handler+0xa8/0xb0
78 | [ 3669.901552]  el0t_64_sync+0x158/0x15c

benhillis on Aug 25, 2022

Same issue here. Qualcomm 8cx gen3 (Thinkpad X13s)

dtgeorge on Aug 24, 2022