Made Visible #3: MLOS, Where Memory Means Something Else

Part 1 drew a microkernel’s flash. Part 2 drew a conventional kernel’s frames and mappings. This one is neither.

MLOS is a Rust kernel that boots in a VM and treats resident model state — weights, KV blocks, activations — as kernel objects with residency and tiering, the way Unix treats pages. What is drawn here is its storage and memory: weight tiles arranged in layers, colored by the tier they are resident in — disk, DRAM, or system RAM.

Resource	Link
MLOS	sw-ml-study/sw-os-ml
How it works	Made Visible #1
Comments	Discord

MLOS

MLOS: weight tiles in layers, then one selected, then recolored by tier --- the same viewer, MLOS's own vocabulary.

MLOS is the one that breaks the pattern. It is a Rust kernel, it boots in a VM, and its scarce resource is neither flash nor physical frames but resident model state — weights, KV blocks, activations — which it treats as kernel objects with residency and tiering the way Unix treats pages.

So across the three, “where is it in memory” means three different things: a block offset in a flash device, a physical frame behind a virtual mapping, and a model object that is either resident or not. Different machines, different decades of hardware, different units of accounting.

Same picture, because the question underneath is the same one: what is here, who owns it, and what class of thing is it? That is the point of showing more than one. A visualizer that only ever drew SWTOS would be a SWTOS feature. Drawing systems that share nothing but the question makes it a tool.

What three systems bought

One system drawn well is a feature of that system. Three systems that share nothing but the question — what is here, who owns it, what class of thing is it — make it a tool, and they are the reason the boundary in part 1 was worth drawing where it was.

The visualizer still does not know what an operating system is. It never learned, across three of them.