High CPU usage under WSL even when vscode is idle

[tusharsnx]

Type: Bug

1. Open vscode with wsl:

   (wsl)$ code .

2. Use htop or similar tool to monitor CPU usage when vscode is idle or minimized to the taskbar.

Expected: CPU usage for vscode's remote server should stay around 0% at idle conditions.

Actual: CPU usage stays between 2-10 %

VS Code version: Code 1.91.1 (f1e16e1e6214d7c44d078b1f0607b2388f29d729, 2024-07-09T22:06:49.809Z) OS version: Windows_NT x64 10.0.26100 Modes: Remote OS version: Linux x64 6.6.36.3-microsoft-standard-WSL2

System Info

|Item|Value| |---|---| |CPUs|11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz (8 x 3110)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled| |Load (avg)|undefined| |Memory (System)|15.79GB (6.69GB free)| |Process Argv|| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|WSL: Ubuntu-22.04| |OS|Linux x64 6.6.36.3-microsoft-standard-WSL2| |CPUs|11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz (8 x 0)| |Memory (System)|7.65GB (6.82GB free)| |VM|0%|

Extensions (10)

Extension|Author (truncated)|Version ---|---|--- remote-wsl|ms-|0.88.2 material-icon-theme|PKi|5.6.0 vim|vsc|1.27.3 markdown-checkbox|bie|0.4.0 gitlens|eam|15.2.0 prettier-vscode|esb|10.4.0 hexeditor|ms-|1.10.0 advanced-new-file|pat|1.2.2 vscode-fileutils|sle|3.10.3 even-better-toml|tam|0.19.2

[tusharsnx]

I had earlier opened the issue at #222412 where I provided more in-depth issue description. I'm just going to put the same description here.

Issue Description

I recently noticed high CPU usage and faster battery drain (intel cpu) when working with any project under WSL. To find out what's taking so much cpu time (even when I'm doing nothing, apart from staring at the screen), I used htop to list processes in the order of cpu usage:

Looked like vscode's remote server running inside wsl is taking CPU. So, I went a little further to profile the running instance of the remote server and I found:

I from extensionHostProcess.js is being called at a regular interval with a small delay (~1000ms). I:

I was able to trace I back to findCandidatePorts():

And I finally found where it is being called repeatedly:

Now, why is it a bug? Because I've disabled all remote.autoForwardPorts related settings in my config, yet the tunnel monitoring service is running in the background. I expect the service to not be running when remote.autoForwardPorts or related configs are disabled. The service is currently always running.

[aeschli]

@tusharsnx Wow, great job, thanks for tracking down the problem!

[alexr00]

@connor4312 I'm having trouble understanding this:

https://github.com/microsoft/vscode/blob/c8c55ab201ba6946d7edfd15519eb86d83d0b869/src/vs/workbench/api/common/extHostExtensionService.ts#L901-L904

Is WSL going to end up being a ManagedResolvedAuthority? I don't think we actually want to show the ports view in WSL even if the Tunnels extension isn't installed.

[connor4312]

I agree. For non-managed remote authorities created just via the remoteAddress in the workbench, how did we determine whether or not to show the ports view? We should apply the same logic here...

[alexr00]

The ports view is controlled by a context key getting set. It gets set in two ways:

1. By an extension that wants the ports view. This is what dev containers does.
2. By a tunnel factory getting added. Since the tunnel factory is always added now, we're always enabling it.

I should be able to add a check if the tunnel factory is coming from an extension and only do 2 if that's the case.

[alexr00]

Looks like we also show the ports view when there's an extension with an onTunnel actiation event:

https://github.com/microsoft/vscode/blob/35af2fb2086606481fd5f77976748dcc15304176/src/vs/workbench/services/remote/common/tunnelModel.ts#L510-L513

Is this perhaps no longer needed with the work you did for tunnels @connor4312? I don't remember exactly why I added it.

[alexr00]

I've moved the onTunnel check to happen when there's been a port forwarded.

[alexr00]

Looks like this was actually a feature: https://github.com/microsoft/vscode-remote-release/issues/4923

You can set "remote.autoForwardPortsSource": "output" to disable this.

I'm also going to try to improve the description of remote.autoForwardPorts and remote.autoForwardPortsSource.