Set process priority

[laggingreflex]

It seems it's currently impossible to set CPU priority for bash or any of its sub processes. I know the use case probably is very slim, mine is to only set an especially CPU hogging ffmpeg process right now. But could it be made possible in future? Or is there any other underlying issue/feature which if solved would make this possible as well?

[rodrymbo]

Did you try nice (on the bash side)?

[laggingreflex]

I did just now, I think it only lowers the priority in bash environment, in relation to other bash processes.

My measure criteria is a small Rainmeter clock/cpu meter skin which slows down considerably when any other window process with same default priority takes up too much cpu, so it's really noticable. Compared to when I lower the priority of ffmpeg.exe which makes it run normal again.

[fpqc]

@laggingreflex if MS implements something maybe like dummy read-only windows processes in /proc, that could make it work, right? That way you can set your process priority for windows stuff in windows and for linux in WSL

[russalex]

Great idea.

This is one of those features which we know about but is pretty low on our backlog. Best way to communicate the desire here would be to go vote on the User Voice page.

[Efreak]

Nice values are weird. I tried setting process priority from process hacker, and the nice value shot up to 4294967295 as seen in htop. Then I tried each setting (Realtime, High, Above Normal, Normal, Below Normal, Idle) and all of them do the same thing.

[yuriiz]

+1

Tried both nice inside bash and start /low bash. All bash's child processes still get Normal priority.

[fpqc]

@yuriiz That's because the priority isn't being set like that. When you start /low bash, you are setting, effectively, the priority of a client (bash.exe) for the lxssmanager service. The pico processes are inheriting the priority from lxssmanager.

bash.exe is basically a tiny little client process that hooks up to a pipe on the service's COM interface and makes Windows Console API calls that set the console mode to automagically render in/out the xterm control sequences. The real magic is split between the session manager service and the kernel driver. However, I bet if you edited the service priority in services.msc, you could globally set the priority on the pico processes.

( Well, at least that's all that bash.exe used to do. Since the big interop upgrade a month or two ago, it's hooked up in a much more sophisticated way to allow passing window control back and forth between windows and linux console programs. )

[mmortal03]

However, I bet if you edited the service priority in services.msc, you could globally set the priority on the pico processes.

How might a person go about doing this? I don't think there's an option for that in services.msc.

[rdp]

wish I didn't need "sudo" for the nice command tho...

[therealkenc]

wish I didn't need "sudo" for the nice command tho...

That's why they invented sudoers

[julien-h2]

So, is there a way to set a wsl process to lower priority?

[danieldjewell]

@rdp @therealkenc

sudo

You can use sudo to start a shell ... (e.g. sudo bash or sudo zsh) ... although doing this regularly for things other than specific admin tasks is (and has been) a topic of much debate in the *NIX community for ... probably 4 decades? (As it is equivalent to logging in as root ... which has its uses, but many strongly frown upon using the root account for anything but system administrative tasks... Interestingly, the voraciousness of the argument against using root is much stronger than the argument against using "Administrator" in the NT/Windows world - at least that I've heard. Might just be me.)

You can also edit /etc/sudoers to make it so that your account doesn't require a password for sudo invocation. (Only using visudo -- check man visudo -- which will launch whatever editor $EDITOR is set to. The reason to use visudo and not just edit it is that visudo will do a syntax sanity check on the edits to make sure you don't mess up the file.) Some might argue that this is a security issue - eh, in certain situations, yes ... but on a WSL install, it's probably fine.

Just add the following below the %sudo line (which refers to members of the sudo group ... replace "user" with your linux/WSL "inner" username):

user      ALL=(ALL)       NOPASSWD:  ALL

---

That said, as of 1909/18363.535 I don't even see a process called lxssmanager (or anything *lxss*) running. Only wsl.exe and wslhost.exe ... Changing process priority on those is possible but it doesn't seem to have had an effect?

I'm not sure if there were some changes made, but WSL processes do show up in task manager and when using Get-Process in PowerShell. However, I can't set the process priority class (either through task manager, through PowerShell running as administrator, or even PowerShell running as SYSTEM by using psexec -s -i powershell ...)

It would appear that there is some Windows Kernel stuff going on here that's not implemented?

Is it possible to set the priority of all WSL processes? (I mean, in some cases, that'd be better than nothing at all.) Or is the priority as far as the Windows Kernel is concerned locked on "Normal"?

[IanPNewson]

@therealkenc Why is this closed? I still get an error when trying to change process priority in WSL2.

[Efreak]

@IanPNewson you might want to check and make sure you're actually using WSL2 and not WSL1. WSL2 is supposed to be using hyper-v virtualization to run a full Linux kernel, not just implementing a subset of the Linux kernel like WSL1. I'm still on WSL1 (all I want is nginx and SFTP) so I'm not 100% sure, but I wouldn't expect WSL2 Linux processes to show up at all in windows task manager; if you're inside Linux and having issues, make sure that you're actually running WSL2 and that you're not running into permission issues (trying to modify something running under another user).

[IanPNewson]

@Efreak ah you were right, I had upgraded to WSL2 but that particular distribution was still on WSL1. Thanks!