Change subprocesses to run at normal priority (#42715)

[Binary-Song]

Fixes microsoft/vcpkg#42715

The priority was changed to NORMAL_PRIORITY_CLASS so vcpkg can perform its tasks (building, zipping, etc) much faster.

[dg0yt]

I expected only a small effect in vcpkg-tool CI, but ... I see that Windows end-to-end test for this PR took only 15 min, vs. 25 min in previous runs.

FTR this might increase memory pressure, with much more active cores as described in microsoft/vcpkg#42715.

[autoantwort]

My experience is that ci times are not a reliable measurement because you never know under which conditions it was run. So local benchmarks would be more reliable.

[dg0yt]

True, but these test aren't massive workloads anyways.

[Binary-Song]

FTR this might increase memory pressure, with much more active cores as described in microsoft/vcpkg#42715.

That is true, but this can be solved by adjusting VCPKG_MAX_CONCURRENCY. On the other hand, there is currently no way of telling vcpkg to run build tools at normal priority, which is a huge waste on CI resources. In comparison, tools like cmake/ninja always build at normal priority, letting the user figure out how many cores to use without running out of mem, so I think it makes sense for vcpkg to do the same.

On a side note, zipping (the post build packaging phase) was ridiculously slow for llvm when run in low priority, that may be a 30 min vs 5 min difference (I will probably submit a benchmark when I have time).

[BillyONeal]

This was done intentionally in ras0219-msft/vcpkg@a24ccdf

@ras0219-msft Do you remember why this was set to IDLE_PRIORITY_CLASS? That seems wrong. I could imagine below normal but not idle. This might explain why we have seen such variable perf in CI.

[BillyONeal]

Is the problem fixed if you use BELOW_NORMAL rather than NORMAL? I can see an argument of not wanting to make interactive stuff on the system stuttery during a build being a reason to choose lower than normal, but idle may be triggering other forms of throttling like you describe in your issue filing.

[Binary-Song]

Unfortunately the improvement was not obvious. With VCPKG_MAX_CONCURRENCY set to 24, BELOW_NORMAL makes the compilers occupy around 10 cores, while NORMAL makes them occupy all 24 cores. I just changed the priority of Ninja.exe while it is running, and the effect was instant.

BELOW_NORMAL:


NORMAL:

[Neumann-A]

I think this is kind of intended. Otherwise machines become completely unresponsive.
Is this Win10?

I don't see the same problem with 24 AMD cores and Win11 building LLVM

[dg0yt]

How does Windows (10 vs. 11) handle power vs. efficiency cores for these scheduling levels?

[Binary-Song]

I have a win11 machine with 32 AMD cores in my workplace and it also has this issue.

[Binary-Song]

I think this is kind of intended. Otherwise machines become completely unresponsive.

I think that is a trade-off that should be left for the users to decide. Currently we already have VCPKG_MAX_CONCURRENCY for that.

[Thomas1664]

I think this is kind of intended. Otherwise machines become completely unresponsive.

I think setting process priority to idle was just a workaround for poor memory management by Windows. Also, this was changed to idle back in 2017 so I would expect this to be fixed in Windows by now. High memory usage is just a problem if you run out of swap. My MacBook sits constantly at 90% memory usage and still runs flawlessly.

Even if idle priority would still be necessary, I don't think locking users into slow builds is a good idea. At the bare minimum there should be an escape hatch.

[Binary-Song]

@BillyONeal What do you think? If you merge this, you are the hero that saves users millions of dollars 😉!

[Thomas1664]

@BillyONeal What do you think? If you merge this, you are the hero that saves users millions of dollars 😉!

Now they'll never merge this cause it means that Microsoft would loose millions of dollars

[Binary-Song]

@BillyONeal