What Outranks Thread Priority?

Excellent writeup of a useful technique. I&#x27;m going to have to learn how to do this myself one day. Of course, if you&#x27;re not inside Microsoft it may be very hard to fix any of it.<p>It really does show how the CPU gains of the past decades have been immediately wasted by badly organised processes doing work inefficiently which is then immediately discarded, while simultaneously blocking more important work.

The Windows kernel scheduler causes much trouble for our simulation software which runs 7 out of 8 cores at full pace, and then mysteriously gets suspended by the kernel when left to run over night. No Microsoft, its not OK to suspend a user task, and it’s not OK to reboot my box for an update while I’m running simulation software. If I end up having to reboot to a non Microsoft OS to run the simulations, I may End up never rebooting back to Win10 (once a solution to our external 3rd party tools is found).

for the *nix among us, the equivalent is the scheduling class (SCHED_FIFO, SCHED_RR, SCHED_OTHER). A given (kernel) thread&#x27;s priority only applies within its scheduling class; if there are ready-to-run threads in a higher &quot;ranked&quot; scheduling class, threads in the lower &quot;ranked&quot; classes will not run.<p>This is widely used when using Linux (for example) as a soft-real time system. The same basic concepts apply to macOS (since they really come from POSIX and even Mach inherited them).

Great Post!<p>You would think that unlocking the screen would be highest priority task for a general purpose OS after it has woken up from sleep, but surprising to see that other processes manage to outrank it.<p>Whats interesting to me is that this LockApp.exe was waiting to get the CPU for a full 19 seconds after it was ready. 19 seconds should be an eternity, I guess.<p>Since the screen was locked and LogonUI.exe had not got the chance to run yet, what other processes were holding on to CPU at that time. Any ideas on that?

There is a whole series of very interesting (even exciting) analyses by this author (randomascii, Bruce Dawson). Most of them are using his own tool UIforETW (<a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;UIforETW&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;UIforETW&#x2F;</a>).<p>I wonder, what alternative tool would you use on Mac? I guess Xcode Instruments in some variant? And this is based on DTrace, right? Would that give you all the same possibilities and traces as UIforETW?<p>And what alternative tool would you use on Linux? perf? eBPF? That would give you the same information as UIforETW? And what GUI would be similar to UIforETW or Xcode instruments?

As someone who spends most of the time in *nix... Windows just sounds nightmarish to debug. The few times I&#x27;ve had to debug something in Linux kernel space I was super glad I had the full source code.<p>All that effort, and then... &quot;the problem magically went away and we&#x27;ll probably never know the true root cause&quot;

Fascinating analysis! Thank you. I have noticed this effect is especially prominent on corporate laptops configured with monitoring features. I notice a similar effect on entering standby. Wonder if it’s related to another Rank 2 demotion of a critical process.

My laptop&#x27;s startup time reduced by few seconds, since I tried the mitigation steps.<p>I hope Bruce looks into other issues too