Senior Engineer @Qualcomm What makes a system well-engineered?
void*
Joined June 2024
- Tweets1.1K
- Following1K
- Followers5.3K
- Likes157K
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…
The best article!
Hello you fine Internet folks,
Today we are looking at Qualcomm's System Level Architecture found in the Snapdragon X2 Elite Extreme SoC and how it handles memory access from both the CPU and GPU side.
Hope y'all enjoy!
chipsandcheese.com/p/qualcom…
Is AI good at multi threading?
Personal experience is that I had to clean up a lot of mess it created. It's not bad but it increases the chances of race conditions by a lot.
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 :)
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.
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.
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…
