Senior Engineer @Qualcomm What makes a system well-engineered?
void*
- Tweets 1,070
- Following 1,028
- Followers 5,286
- Likes 153,177
Pinned Tweet
Read “Windows Internals: Thread Management — Part 1“ by OS Dev on Medium:
This article discusses about ETHREAD, KTHREAD kernel objects & windows scheduler - how it schedules a thread.
medium.com/windows-os-intern…
3
30
205
23,060
I always wondered what Priority, Preemption, QoS, CPU Affinity and NUMA actually mean when it comes to scheduling. We hear these terms separately, but they all somehow meet when the OS has to answer a simple question: “this thread is ready, where and when should I run it?” I’m going down this rabbit hole now :)
35
1,250
It’s crazy how advanced modern OS schedulers are. When a thread is ready, the scheduler doesn’t just find a free CPU and run it. It has to think about priority, CPU load, affinity, which core the thread ran on before, cache locality, CPU topology, and on heterogeneous systems, which type of core is a better fit. Move the thread too much and you can lose cache locality. Keep it on one busy core and you lose performance. Put background work on a high-performance core and you may waste power. And these decisions happen continuously while hundreds or thousands of threads are waking, sleeping, blocking and competing for CPU time. Scheduling today is as much about power and hardware topology as it is about sharing CPU time.
4
11
277
12,374
Windows NT 3.1 had an interesting bug where starting an application with "START /REALTIME" could make the OS appear to hang. "/REALTIME" put the process in the real-time priority class, where its threads could run above normal dynamic-priority threads and potentially starve lower-priority work.
Microsoft documented this as Q103475: “Starting Applications with /REALTIME May Hang Windows NT.” Interestingly, "REALTIME_PRIORITY_CLASS" still exists in Windows today, and Microsoft still warns that misuse can interfere with important system work.
4
1
48
3,215
One surprising fact about the first Windows NT: NT meant “New Technology,” and NT 3.1 wasn't built just for Windows apps. It was designed with multiple environment subsystems, supporting Win32, POSIX and character-based OS/2 apps on top of the same NT architecture. Windows was basically one personality on top of NT. Pretty wild for 1993.
Say what you will about Windows (OS), but the NT kernel really is an engineering marvel that still puts Linux to shame in many ways.
The quickest way to describe it for a programmer, is NT was more like an object-oriented language, with a strong security model from day one, whereas Linux is very…not.
A lot of the “good” features in Linux feel bolted-on (SELinux, Capabilities, Namespaces) because…well they were. I love to imagine an alternate history where NT won.
IMO, Microsoft *should* have made an “Open NT” in the early 2000s; not fully GPL-style open, but one where a large org could say…swap out a memory allocator for their own. (they sorta did this with limited source access, but it was too restrictive)
You could imagine say…an early Amazon forking OpenNT to create an “AmazonNT” for EC2, where they have a modified scheduler, network stack, whatever. But, the security+compatibility contract keeps a stable baseline on the Microsoft side.
Controversial take, but if we enter this era where users are giving AI agents increasingly higher levels of access control; the Linux kernel is legitimately a poor fit. Think about it; answer the question “What exactly is this AI agent allowed to do?”
On Standard Linux, it’s disgustingly messy with lots of overlap.
Do you use UIDs? GIDs? ACLs? CGROUPs? Policies? SELinux? Filesystem modes? There’s not a singular coherent graph of capabilities you can point to. Too many ways you can escape an initially narrow scope.
NT, by comparison, can go the route of explicitly typed resources, and then you could have these really strong centralized audit trails when an agent goes haywire…etc.
I know I’m rambling, but the point is…if you were greenfielding an OS kernel from scratch, in 2026, with the intent of being forward-looking, it would *not* look like Linux. Frankly, it’d probably look a lot closer to NT, or even a BSD fork…
10
8
145
47,897
You probably keep seeing 40 TOPS, 50 TOPS, 80 TOPS whenever companies talk about NPUs.
But what exactly is TOPS?
TOPS = Trillion Operations Per Second.
Very simply, it is a measure of the peak compute throughput of an NPU under a particular datatype and counting convention.
AI workloads involve a huge amount of matrix math, where multiply-accumulate operations (MACs) are extremely common.
Think of:
"a × b + c"
That's one multiply + one addition.
When the multiply and addition are counted separately, one MAC is counted as 2 operations.
So a common peak calculation is:
"TOPS = 2 × MAC units × frequency / 10¹²"
That's how thousands of compute units working in parallel can reach trillions of operations every second.
So 50 TOPS means a stated peak throughput of 50 trillion operations per second under the precision and counting method used for that specification.
But here's the important part:
A 50 TOPS NPU isn't automatically faster than a 40 TOPS NPU.
You still need to ask:
→ Is it INT8, INT4, FP16, etc.?
→ Is the number dense TOPS or sparse TOPS?
→ Can the workload actually keep the NPU busy?
→ Is memory bandwidth/data movement becoming the bottleneck?
→ How efficiently can the compiler/runtime map the model onto the hardware?
Precision matters a lot too.
Lower-precision operations require less data and can often allow the hardware to execute more operations per second. So 50 INT8 TOPS and 50 INT4 TOPS are not automatically equivalent measurements of capability.
And even two NPUs with the same INT8 TOPS can perform very differently on the same model.
Because TOPS tells you about peak compute throughput, not guaranteed application performance.
Real AI performance also depends on model architecture, memory bandwidth, data movement, software/runtime efficiency, power limits and thermals.
So whenever you see:
NPU: 50 TOPS
read it as:
“This NPU has a stated peak throughput of 50 trillion operations per second under a particular precision and counting convention.”
Not:
“This NPU will always be faster.”
1
24
1,256
👀
You asked. We listened.
The @Linux on @Snapdragon X2 Series Early Developer Preview is here. It's an early milestone, with support rolling out in phases, but developers can start exploring, testing, and providing feedback already today: bit.ly/3V2ARKp
Join our Discord and help shape the future of Linux on Snapdragon: bit.ly/4u7A2LX
16
1,179
One interesting Windows internal that Win32 normally hides from us: "OBJECT_ATTRIBUTES".
When you go closer to the NT Native API, you'll see functions like "NtOpenFile()" take an "OBJECT_ATTRIBUTES" structure.
It basically tells Windows which object you're referring to and how its name should be resolved.
It contains things like:
-> "ObjectName" - a "UNICODE_STRING" containing the object name
-> "RootDirectory" - optional handle used as the root for a relative object name
-> "Attributes" - flags like "OBJ_CASE_INSENSITIVE"
-> "SecurityDescriptor"
-> "SecurityQualityOfService"
-> "Length"
But the interesting part is "ObjectName" + "RootDirectory".
Windows has an Object Manager namespace starting at "\", with directories like:
"\Device"
"\KernelObjects"
"\DosDevices"
These are not normal folders on your disk. They are part of the namespace maintained by the Windows Object Manager and can contain different types of kernel objects.
For example, an API could refer to an object using a full name:
"\Device\Beep"
But it can also open an appropriate root object first, put that handle in "RootDirectory", and then use a relative "ObjectName".
So instead of always looking up the full path, the Object Manager can resolve the name relative to an existing handle.
It's one of those structures you rarely think about when using normal Win32 APIs, but once you start looking at Native APIs and Windows kernel code, "OBJECT_ATTRIBUTES" shows up everywhere.
Another layer of Windows that Win32 quietly hides from us.
trainsec.net/library/windows…
1
14
98
3,184
Technology is such a weird thing.
We created the internet to connect everything, then started adding TLS, certificates, cryptography, firewalls, authentication etc. to make that connection secure.
We created virtual memory to make memory management and isolation easier, then added TLBs, page-walk caches, huge pages etc. to make address translation fast.
CPUs became faster than memory, so we added L1, L2, L3 and sometimes system-level caches. Then we needed complex cache coherency protocols to keep all of them in sync.
We created filesystems to make storage easier, then added permissions, journaling, encryption like BitLocker, checksums, snapshots etc.
It's basically invent something -> discover new problems -> build another layer to solve them -> that layer introduces another problem -> repeat.
And that's not necessarily bad. That's how we learn and evolve.
But sometimes I wonder... can computing ever really restart?
Can we throw away decades of compatibility, abstractions and workarounds and build something completely new from scratch?
Or will we just keep adding layers forever?
3
5
81
2,553
Googlebook on @Qualcomm's snapdragon :)
First, the hardware had to be amazing.
We partnered with the best PC makers in the world—Acer, ASUS, Dell, HP, and Lenovo—to establish a new standard for premium hardware craft. Every single Googlebook meets strict minimum specs so you get uncompromised performance and build quality.
Materials: Precision aluminum, magnesium, & carbon fiber
Displays: High-density touchscreens up to 2.8K OLED
Silicon: Next-gen Intel & Qualcomm chips w/ 45+ TOPS NPUs
Memory & Power: Standard 16GB RAM & up to 14 hours active battery
Read more about the hardware lineup here: blog.google/products-and-pla…
1
10
1,124
One interesting Windows internals detail I didn't know:
Windows has an undocumented ETW flag called "SecurityTrace".
When this flag is set on an ETW session, querying that session requires the caller to be at least Antimalware-PPL. Even running as SYSTEM isn't enough.
This is relevant to "Microsoft-Windows-Threat-Intelligence", a powerful ETW provider used for security telemetry.
Normally, enabling this provider from user mode requires Antimalware-PPL.
But AutoLoggers are different.
They are configured in the registry and started by the kernel during boot. If an AutoLogger contains the Threat-Intelligence provider, Windows automatically marks that ETW session with "SecurityTrace".
There is no user-mode PPL caller to validate during that AutoLogger enable path. Instead, access is restricted later through "SecurityTrace".
And this is where things get interesting.
Real-time ETW consumers normally use:
"OpenTrace" -> "ProcessTrace"
Internally, these APIs query the trace properties. For a "SecurityTrace" session, that QUERY eventually reaches the kernel and requires Antimalware-PPL.
But the researchers found that the consumer-side QUERY is initiated through "sechost.dll" inside the caller's own process.
So an administrator can avoid that QUERY path, or intercept "ControlTrace" QUERY and provide the required trace properties locally.
The result:
An administrator can consume events from "Microsoft-Windows-Threat-Intelligence" without running as Antimalware-PPL and without loading a kernel driver.
Another interesting detail:
"SecurityTrace" protects QUERY with the Antimalware-PPL check, but STOP does not enforce the same PPL requirement. A sufficiently privileged non-PPL process that knows the session and satisfies its DACL can stop it.
There are still limits. Some additional Threat-Intelligence telemetry requires per-process opt-in through "NtSetInformationProcess", and that operation still requires Antimalware-PPL.
Microsoft's MSRC reviewed the research and did not classify it as a vulnerability, noting that the Administrator <-> PPL boundary is not considered an enforceable security boundary.
A fascinating example where the important question isn't only:
"Is this resource protected?"
but also:
"Where exactly is that protection enforced?"
1
7
50
2,933
Source: core-jmp.org/2026/09/etw-sec…
2
216