They didn’t embrace Linux; they surrendered to its inevitability.

Microsoft’s Linux Love Letter: A Necessary Dose of Historical Context

A headline caught my eye recently, one in a long series of similar pieces from Microsoft: a celebratory look back at their 2009 contribution of 20,000 lines of code to the Linux kernel. The narrative is one of a new leaf, a turning point, a company evolving from a closed-source fortress into a collaborative open-source neighbor.

And on its face, that’s a good thing. I am genuinely glad that Microsoft contributes to Linux. Their work on Hyper-V drivers and other subsystems is technically sound and materially benefits users running Linux on Azure. It’s a practical, smart business move for a company whose revenue now heavily depends on cloud services that are, in large part, powered by Linux.

But as I read these self-congratulatory retrospectives, I can’t help but feel a deep sense of whiplash. To present this chapter without the full context of the book that preceded it is not just revisionist; it’s borderline insulting to those of us who remember the decades of hostility.

Let’s not forget what “building and collaborating” looked like for Microsoft before it became convenient.

This is the company whose CEO, Steve Ballmer, famously called Linux “a cancer” in 2001. This wasn’t an off-the-cuff remark; it was the public-facing declaration of a deeply entrenched corporate ideology. For years, Microsoft’s primary strategy wasn’t to out-build Linux, but to use its immense market power to strangle it.

They engaged in a brutal campaign of FUD (Fear, Uncertainty, and Doubt):

  • They threatened patents, suggesting that Linux and other open-source software infringed on hundreds of Microsoft patents, aiming to scare corporations away from adoption.
  • They entered into costly licensing agreements with other tech companies, essentially making them pay “protection money” against hypothetical lawsuits.
  • They argued that open-source software was an intellectual property-destroying “communist” model that was antithetical to American business.

This was not healthy competition. This was a multi-pronged legal and rhetorical assault designed to kill the project they now proudly contribute to. They didn’t just disagree with open source; they actively tried to destroy it.

So, when Microsoft writes a post that frames their 2009 code drop as a moment that “signaled a change in how we build and collaborate,” I have to ask: what changed?

Did the company have a moral awakening about the virtues of software freedom? Did they suddenly realize the error of their ways?

The evidence suggests otherwise. What changed was the market. The rise of the cloud, which Microsoft desperately needed to dominate with Azure, runs on Linux. Their old strategy of hostility became a direct threat to their own bottom line. They didn’t embrace Linux; they surrendered to its inevitability. The contribution wasn’t a peace offering; it was a strategic necessity. You can’t be the host for the world’s computing if you refuse to support the world’s favorite operating system.

This isn’t to say we shouldn’t accept the contribution. We should. The open-source community has always been pragmatically welcoming. But we should accept it with clear eyes.

Praising Microsoft for its current contributions is fine. Forgetting its history of attempted destruction is dangerous. It whitewashes a chapter of anti-competitive behavior that should serve as a permanent cautionary tale. It allows a corporation to rebrand itself as a “cool, open-source friend” without ever fully accounting for its past actions.

So, by all means, let’s acknowledge the 20,000 lines of code. But let’s also remember the millions of words and dollars spent trying to make sure those lines—and the entire ecosystem around them—would never see the light of day. The true story isn’t one of a change of heart, but a change of market forces. And that’s a history we must never let them forget.

Kernel Hell: SLUB Allocator Contention on NUMA Machines

So here’s a weird rabbit hole I went down recently: trying to figure out why Linux memory allocation slows to a crawl under pressure — especially on big multi-socket systems with a ton of cores. The culprit? Good ol’ SLUB. And no, I don’t mean a rude insult — I mean the SLUB allocator, one of the core memory allocators in the Linux kernel.

If you’ve ever profiled a high-core-count server under load and seen strange latency spikes in malloc-heavy workloads, there’s a good chance SLUB contention is part of it.

The Setup

Let’s say you’ve got a 96-core AMD EPYC box. It’s running a real-time app that’s creating and destroying small kernel objects like crazy — maybe TCP connections, inodes, structs for netlink, whatever.

Now, SLUB is supposed to be fast. It uses per-CPU caches so that you don’t have to lock stuff most of the time. Allocating memory should be a lockless, per-CPU bump pointer. Great, right?

Until it’s not.

The Problem: The Slow Path of Doom

When the per-CPU cache runs dry (e.g., under memory pressure or fragmentation), you fall into the slow path, and that’s where things get bad:

  • SLUB hits a global or per-node lock (slub_lock) to refill the cache.
  • If your NUMA node is short on memory, it might fallback to a remote node — so now you’ve got cross-node memory traffic.
  • Meanwhile, other cores are trying to do the same thing. Boom: contention.
  • Add slab merging and debug options like slub_debug into the mix, and now you’re in full kernel chaos mode.

If you’re really unlucky, your allocator calls will stall behind a memory compaction or even trigger the OOM killer if it can’t reclaim fast enough.

Why This Is So Hard

This isn’t just “optimize your code” kind of stuff — this is deep down in mm/slub.c, where you’re juggling:

  • Atomic operations in interrupt contexts
  • Per-CPU vs. global data structures
  • Memory locality vs. system-wide reclaim
  • The fact that one wrong lock sequence and you deadlock the kernel

There are tuning knobs (/proc/slabinfo, slub_debug, etc.), but they’re like trying to steer a cruise ship with a canoe paddle. You might see symptoms, but fixing the cause takes patching and testing on bare metal.

Things I’m Exploring

Just for fun (and pain), I’ve been poking around the idea of:

  • Introducing NUMA-aware slab refill batching, so we reduce cross-node fallout.
  • Using BPF to trace slab allocation bottlenecks live (if you haven’t tried this yet, it’s surprisingly helpful).
  • Adding a kind of per-node, per-type draining system where compaction and slab freeing can happen more asynchronously.

Not gonna lie — some of this stuff is hard. It’s race-condition-central, and the kind of thing where adding one optimization breaks five other things in edge cases you didn’t know existed.

SLUB is amazing when it works. But when it doesn’t — especially under weird multi-core, NUMA, low-memory edge cases — it can absolutely wreck your performance.

And like most things in the kernel, the answer isn’t always “fix it” — sometimes it’s “understand what it’s doing and work around it.” Until someone smarter than me upstreams a real solution.