# Windows 11 KB5089573 multithreading issues

**URL:** <https://discourse.julialang.org/t/windows-11-kb5089573-multithreading-issues/137312>\
**Category:** General Usage\
**Tags:** multithreading\
**Created:** [May 28, 2026, 10:25am UTC](https://discourse.julialang.org/t/windows-11-kb5089573-multithreading-issues/137312 "2026-05-28T10:25:02Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![arch-dev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/arch-dev/32/220740_2.png) [@arch-dev](https://discourse.julialang.org/u/arch-dev)\
**Post date:** [May 28, 2026, 10:25am UTC](https://discourse.julialang.org/t/windows-11-kb5089573-multithreading-issues/137312/1 "2026-05-28T10:25:02Z")

</div>

Today, I’ve installed the KB5089573 update which brings the so called “Low Latency Profile” feature to Windows 11 (more information [here](https://www.windowscentral.com/microsoft/windows-11/microsoft-rolls-out-windows-11-kb5089573-update-that-makes-your-pc-genuinely-faster-and-more-responsive)). Up to now I’ve never had any issues with multithreading. My usage case is a while loop which numerically integrates two trajectories simultaneously by spawning two threads each iteration:

```julia-auto
@inbounds while t[it-1] < tf
    dt = min(dt0, tf - t[it-1])

    thr1 = Threads.@spawn velocityverlet!(...)
    thr2 = Threads.@spawn velocityverlet!(...)

    wait(thr1)
    wait(thr2)

    # Perform some tasks over the results

end

```

I usually start Julia in VSCode with the argument `--threads=32`, and the computational speed is about `100 iterations/1.5 seconds` with a CPU usage of about 28%. Today, after the update, I’ve run the same simulation and I’ve noticed a significant performance degradation: `100 iterations/4 seconds` with a CPU usage of 80% and almost 14/16 cores maxed out.

After some trial and error, I’ve found out that starting julia with `--threads=auto` fixes the issue.

Am I missing something? Thanks in advance for your help.

### Additional information

```julia-auto
julia> versioninfo()
Julia Version 1.12.6
Commit 15346901f0 (2026-04-09 19:20 UTC)
Build Info:
  Official https://julialang.org release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 16 × Intel(R) Core(TM) Ultra 7 255H
  WORD_SIZE: 64
  LLVM: libLLVM-18.1.7 (ORCJIT, arrowlake)
  GC: Built with stock GC
Threads: 1 default, 1 interactive, 1 GC (on 16 virtual cores)

```

---

<div class="post-metadata">

**Author:** ![WalterMadelim](https://avatars.discourse-cdn.com/v4/letter/w/3e96dc/32.png) [@WalterMadelim](https://discourse.julialang.org/u/WalterMadelim)\
**Post date:** [May 28, 2026, 12:12pm UTC](https://discourse.julialang.org/t/windows-11-kb5089573-multithreading-issues/137312/2 "2026-05-28T12:12:15Z")

</div>

Can you give more details?

From the current info, you are only running at most 2 tasks in parallel, then how can the CPU usage be 80%? (I assume that the `velocityverlet!` is at most occupying 1 thread).

If the `velocityverlet!` is a cpu-bound task, then perhaps it should be associated with a physical core rather than a virtual processor, so maybe `--threads=32` is not ideal.

---

<div class="post-metadata">

**Author:** ![arch-dev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/arch-dev/32/220740_2.png) [@arch-dev](https://discourse.julialang.org/u/arch-dev)\
**Post date:** [May 28, 2026, 12:50pm UTC](https://discourse.julialang.org/t/windows-11-kb5089573-multithreading-issues/137312/3 "2026-05-28T12:50:29Z")

</div>

Yes. The issue is exactly that: the tasks are just 2 and the CPU is almost maxed out, which is indeed strange. As I said, before the update I’ve started julia with `--threads=32` without issues. Now to achieve the same performance I need to start it with `--threads=auto`.

The following are the some tests I’ve done before discovering that `--threads=auto` solves the issue.

### No running simulation

 ![image](https://global.discourse-cdn.com/julialang/original/3X/7/7/770f0284aba2d4f6429fc30ad90e2f7cea51e935.png)

### Simulation with `--threads=2`

 ![image](https://global.discourse-cdn.com/julialang/original/3X/3/3/33b1d9996c0072f444026d1c3c86ff39ab9e3f03.png)

### Simulation with `--threads=32`

 ![image](https://global.discourse-cdn.com/julialang/original/3X/d/5/d53cc5b22c473c90088372c2a7eccda597840321.png)

### Simulation with `--threads=auto`

 ![image](https://global.discourse-cdn.com/julialang/original/3X/8/7/8761e943be3219047f17746d9ca2f78ccab575c6.png)

The performance of `--threads=2` and `--threads=32` are almost equal (about 100 iterations/4 seconds), while `--threads=auto` gives the usual performance I’ve got before the update, that is 100 iterations/1.5 seconds.

Edit: With `--threads=auto`, `Threads.nthreads() = 16`

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 28, 2026, 1:21pm UTC](https://discourse.julialang.org/t/windows-11-kb5089573-multithreading-issues/137312/4 "2026-05-28T13:21:20Z")

</div>

> [@WalterMadelim](#):
>
> From the current info, you are only running at most 2 tasks in parallel, then how can the CPU usage be 80%?

The GC could automatically use more threads (all tasks would be idle or paused), but I’d expect it to be _faster_. It’s also not certain how many interactive, worker, and GC threads are being used in these scenarios; the documented default is 1 additional interactive thread, don’t know where the default GC threads is described (appears to be the number of worker threads if less than the number of virtual cores, number of virtual cores otherwise on my system). At least we know `auto` means 16 worker threads in that one run (`nthreads` defaults to only counting the default pool, `versioninfo` reports all).

Another possibility is that the CPU is being triggered into running other processes. I have no idea what other processes are around that could warrant so much activity, but the KB5089573 update’s description of “low latency” might be hinting at that. Very uncertain because it’s mostly describing boosting the clock for interactive apps, so I wouldn’t have expected it to affect a program that’s left alone to run. Yet it has, might as well check the Processes tab of Task Manager.