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…

Growing up with financial struggles, in a village or town, with mostly regional-language education shaped my confidence. My school called itself English medium, but hardly anyone taught in English. My parents worked hard to support me. But I was also taught not to question them or any elder, teacher, police officer, rich person, or city person. I grew up feeling like I should always obey and never speak up. That followed me into engineering and work. Struggling to express myself, stumbling over words during presentations, sweating, finding it hard to say no. Being the obedient “nice guy” comes at a cost. Many people around the world grow up this way, constantly worrying about how others see them, afraid of humiliation or awkwardness, and holding themselves back from taking risks. I’m learning to push myself out of my comfort zone, speak up, and stand up for myself. It’s okay to express your thoughts and clarify what you mean when someone misunderstands you. You don’t have to silently accept their version of you. Let yourself be awkward while you practise. Trust me, people care far less about your awkward moments than you think. They have their own lives and worries. That’s how you grow and build confidence. With practice, you can communicate more clearly, feel more comfortable during presentations, and perform better at work. You don’t have to keep holding yourself back. Ask questions. Say no. Make mistakes. Express yourself. Just be mindful of your words and be kind.

The trick to learning fast is to put your ego aside, accept that you don’t understand something yet, and ask “stupid” questions.

Modern SoCs have so many power optimizations. Working in performance engineering exposes us to so many interesting topics :) P-states, DVFS, AMU, PMU, feedback loops... there’s always more to learn.

A stolen website key puts one site at risk. eMudhra’s weak CA keys could let attackers forge HTTPS certificates for any domain. If they intercept your connection and your client still trusts those CAs, they could impersonate your bank and read or modify traffic.

The best article!

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.

Touched some grass this weekend :)

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.

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.”

KUBSAN → catches C/C++ undefined behavior: invalid shifts, signed overflow, alignment violations, certain invalid casts/operations, etc. This is a good sign.

👀

About Qualcomm's Oryon CPU chipsandcheese.com/p/qualcom…

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…

I've been scratching my head since yesterday to identify a deadlock scenario during windows service stop ;( It's reproducing only 1 out of 15 times, very random but a critical one for us.

Is this for real? Benchmark optimizations are considered okay? Rather than generic workload optimizations ?