What Outranks Thread Priority?
randomascii.wordpress.com
randomascii.wordpress.com
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.
I've left calculations running overnight many times on my Windows machine and never had a problem. Was your machine going to sleep based on the power settings? I'll bet that was it.
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).
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.
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.
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?
As he explains, processes with a GUI trying really hard to render despite it not being possible, as the screen hasn't been unlocked yet. Presumably another Windows bug.
Also hardware drivers initializing stuff. Including spinning for an eternity – his mouse and keyboard driver apparently spinned for 700ms.
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?
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?
That said, UIforETW definitely fixes some significant issues with recording and managing ETW traces.
All that effort, and then... "the problem magically went away and we'll probably never know the true root cause"
In the Unix world I feel similarly about things like dtrace. Amazing tool with a learning curve.
I agree about the lack of source - it's really nice to be able to see exactly what the kernel is doing on Linux.
Debug symbols do help a ton on Windows.
But if you want a repository for your own debug symbols, multitude of symbol versions and ease of use then you're out of luck.
I hope Bruce looks into other issues too