Vmmem high CPU usage

[manuelserradev]

Windows Build Number

Microsoft Windows [Version 10.0.21387.1]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.16

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

I'm struggling to actually repro this issue deterministically. But looks like more prominent when waking up from sleep.
Whit this issue I'd like to gather feedback on how to collect the most useful information to debug this behavior.

I tried to isolate the failing component (ex. not running Docker Desktop and WSL2 "only"), but I failed miserably.

Usually my workflow:

• VSCode Stable v1.56.2 with WSL Remote v0.56.2 for work (usually Java + SQL)
• VSCode Insiders v1.57.0 with WSL Remote v0.56.2 for personal projects (usually JS related)
• Docker Desktop (Windows) v3.3.3 (64133) running (with mongo or postgres)

In the past I tried to alleviate the issue with a .wslconfig but didn't worked.

My machine (Lenovo X1 Carbon) has 16GB of RAM and usually Vmmem RAM consumption float around ~4GB.

Excluded those hiccups WSL2 experience is pretty neat and flowlessy.

Expected Behavior

WSL2 stay idle when no user workload are launched.

Actual Behavior

Vmmem "randomly" uses high cpu/power amount (60%-70%) for couple of minutes (2 to 5 min) before settling down. This also happen when on battery without doing anything WSL2 releated (but with Docker Desktop running), killing autonomy.

Diagnostic Logs

I'll provide an .etl dump as the next hiccup occurs.

[manuelserradev]

Today, after wake up from sleep I managed to repro.

wsl.zip

[Matsemann]

I also see high vmmem cpu usage from time to time (stuck at ~25% CPU). When checking htop on my only running image, I see that one core is being used 100%, but none of the processes are using any CPU. So not sure what's happening / what's the culprit. Docker images not running at the moment.

C:\Users\mats>wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-20.04           Running         2
  docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2

Have the opposite problem with docker, though. Suddenly it will use all available ram even when not running any containers (but the wsl distributions are running)

Edit: A pic of htop when this occurs. Nothing visible using CPU, but it's using much CPU on multiple cores anyway.

[manuelserradev]

The day after, also waking up from night sleep.

Like @Matsemann htop do not show anything relevant.

wsl2.zip

[ll931217]

The day after, also waking up from night sleep.

Like @Matsemann htop do not show anything relevant.

wsl2.zip

The high CPU usage can be seen from Task Manager

[Matsemann]

Yes, and from the htop screenshot. But you cannot see what is using the CPU (other than the generic vmmem but that can be anything). So there is something spinning somewhere draining resources for no good reason.

[ChrisJefferson]

I'm hitting this too, so if anyone has any suggestions on how to capture what is going on, I am happy to record it.

[ChrisJefferson]

Update, I can reproduce this 100% of the time by turning off my 2nd monitor (one core in Linux gets pegged to 100%, but htop doesn't show any processes using CPU power).

If I run 'xeyes', as soon as xeyes open the mystery CPU usage disappears, so I assume it's something to do with the new graphics integration, and actually running a program gives it a kick?

[Matsemann]

Great find! I've always experienced it after computer has been sleeping (like when coming back after lunch), but I also can reproduce it by reconnecting a monitor. Which I guess is what happens when the computer starts after sleep.

Running xeyes or any wslg app doesn't seem to stop it here, though.

[Matsemann]

I'm hitting this too, so if anyone has any suggestions on how to capture what is going on, I am happy to record it.

Yes, if someone from wsl team could tell us how to give them better diagnostics that would be nice. As we've said, nothing shows up as using resources in the wsl images themselves. But we can see a high cpu core usage in htop, or vmmem cpu usage in task manager. But don't know how to see what is causing it.

[fmiqbal]

Update, I can reproduce this 100% of the time by turning off my 2nd monitor (one core in Linux gets pegged to 100%, but htop doesn't show any processes using CPU power).

Can confirm,

1. wsl --shutdown, set monitor projection to single screen
2. Startup wsl, normal htop
3. Make monitor projection to extend
4. Suddenly 1 core spin up in htop

I tried messing with refresh rate (my first monitor has 144, my second 60), but no luck. In the process, I found that when I tried to change the refresh rate, the screen "refresh", then the 100% core in htop gone.
So I tried to just reset the graphic driver (Win+Ctrl+Shift+B), and the 100% core is also gone.

Although, currently its fresh restart and reproduced reliably, but only 1 core spinning up. In the past I had like 3 core spinning up out of nowhere. I also use Docker for Windows, which for this purpose I turn off first, because I also had bad experience on that docker hogging CPU while no container running

Update
Using docker for windows, I get 3 core spinning up when projecting to second screen, and Win+Ctrl+Shift+B still works like a charm

Windows 10, build 21390.2025
WSL2, Arch Linux,
2 monitor setup,

[onomatopellan]

I think this is indeed related to WSLg, which creates a hidden "system distro" instance for each running user distro. That's why you can't see anything in htop. When the 100% core usage happens you can run this from the terminal:
wsl.exe --system -d $WSL_DISTRO_NAME top

I bet the culprit is the weston binary inside the system distro. Recently there was a similar problem that has been fixed in the weston repository.

[joewood]

As a possible confirmation of this, I had this issue continuously (with vmmem using 50% of CPU without anything running on WSL2). I disabled WSLg in wslconfig and restarted the distributions. The issue (so far) seems to be fixed.

[onomatopellan]

With wsl.exe --update you will get WSLg 1.0.24 which contains some fixes about high cpu usage.

[joewood]

If it helps, I was already running 1.0.24 (updated yesterday) and still seeing the issue. Disabling WSLg seems to have fixed it. I'll keep testing.