Notes on the OSDI’26 papers closest to my own work. I add papers as I read them.

Break on Through to the Other Side: Pooling Memory Elastically with RamRyder

Yanbo Zhou and Steven Swanson (UC San Diego), with Shanghai Jiao Tong University and Samsung Semiconductor · Paper · Code

• CXL
• Memory tiering
• Virtualization

In one sentence.

Memory bandwidth should be allocated as a cloud resource in its own right, just like CPU and memory capacity.

Background.

• Memory allocation in the cloud is not flexible enough: vendors allocate memory capacity in a fixed ratio to vCPUs and offer no way to allocate bandwidth. The authors’ analysis of Alibaba’s cluster traces shows that 90% of servers exhibit average bandwidth utilization below 44.5%.
• Underutilized bandwidth is not necessarily correlated with underutilized capacity, because they exhibit different spatial and temporal patterns.

Approach.

• RamRyder is a software-defined elastic memory system for cloud VMs that adjusts capacity and bandwidth dynamically, by managing memory at channel granularity.
• Components:
  • Host user space resource manager: channel allocation
  • Hypervisor: virtualize memory channels
  • Modified guest kernel: page-to-channel allocation policies

Evaluation.

• Implemented on unmodified commodity servers
  • Disable existing DIMM channel interleaving via BIOS/UEFI
  • CXL devices reserved as a separate DAX device in user space with CXL configuration tools
• Test setup:
  • AMD EPYC Zen 5 with 12 DDR5 channels per socket; each VM’s vCPUs are pinned to their own CCXs, so VMs do not share an L3 cache
  • 8 of the 12 channels in one socket are used, each populated with one 32 GB DDR5 DIMM, to match compute-optimized cloud instances
  • 4 × 256 GB Samsung CXL 2.0 memory devices
  • Debian with Linux 6.15
• RamRyder improves average capacity and bandwidth utilization by 28.6% and 43.2%, respectively, across the cluster while delivering performance comparable to the best case with exclusive access

Food for thought.

• Limitations: the mapping from physical addresses to memory channels is normally hidden from system software, so deployment means turning off channel interleaving in BIOS/UEFI (a boot-time setting), and the guest kernel must be modified

Finding NEMO: Nimble and Expressive Memory Observability

Shihang Li, Matthew Giordano and Simon Peter (University of Washington), with Meta and Microsoft Azure · Paper · Code

• CXL
• Memory tiering

In one sentence.

A small, programmable telemetry engine in the memory controller lets the OS count exactly the memory accesses it cares about, at the granularity it chooses, without spending CPU time.

Background.

• A long-standing need for easy and efficient hardware and software mechanisms that can track memory usage on multi-tier memory systems.
• Existing mechanisms:
  • page level access bit tracking, expensive
  • hardware cache miss sampling, reduced precision (HeMem)

Approach.

• NEMO, a hardware-software codesigned memory telemetry engine
  • On the hardware side, NEMO is a lightweight extension to memory controllers (MCs)
  • On the software side, NEMO exposes an OS-facing programming model and Linux driver
• MCs already host QoS and monitoring features; the NEMO pipeline runs alongside, rather than on, the memory datapath.
• To support different granularities of monitoring (cache line to multi-GiB regions), the “match stage” masks and shifts the request’s physical address with OS-set parameters (simple fixed-latency arithmetic, not a hash) and looks the result up in a small translation table to find the counter. For page-hotness tracking, a 2 MiB page granularity is adopted

Evaluation.

• Altera Agilex 7 FPGA I-Series Development Kit with CXL 2.0 Type-3 support in hard IP
• SRAM per NEMO pipeline: ~150 KiB
• Across the full bitstream, NEMO uses 4.4% of the FPGA’s M20K SRAM and 4.8% of its logic
• Speeds up HeMem’s reaction to hot-set changes by 5×, accelerates THP splitting in MEMTIS by 10.4×, and detects noisy neighbors in Linux with 350× lower overhead. These telemetry improvements yield up to 1.7× higher throughput and 23% lower latency across key-value stores and databases

Food for thought.

This paper overlaps a lot with my past work.

• One data point from my own experience: scanning the page table (test-and-clear of the accessed bits) for 1 GB of address space (one VMA of 4 KiB pages, memset first so that every PTE really exists) takes about 1 ms, so 1 TB would take about 1 s, long enough for the accessed bits to go stale. And as the authors point out, one bit per page is too coarse-grained.
• 2 MiB granularity is a common, wise and practical choice for page temperature tracking.
• The memory controller is a compelling place for hardware event monitoring. The prototype already sits in a CXL memory expander’s controller; I would imagine future CXL devices shipping such engines to hint the OS and other system software.

Teaching The Old Dog New Tricks: Building Efficient Data Pipelines for Large-Scale LLM Pre-training (Operational Systems)

Luofan Chen and Chenhan Wang (USTC and ByteDance Seed) and Cheng Li (USTC), with ByteDance Seed, ByteDance and Tsinghua University · Paper

• Storage
• LLM training

In one sentence.

ML workloads usually have fixed ranks and predictable access patterns, which creates room for resource pre-allocation and optimizations.

Background.

• Pre-training data pipeline:
  • initialization phase: The training framework issues blocking operations that load full model checkpoints, distributed and replicated across thousands of ranks
  • iterative training phase: The dataloader prefetches and pre-processes data for forward passes and backward passes. The training framework periodically persists checkpoints to storage
  • companion evaluation phase: Each evaluation cycle loads the latest checkpoint from storage, executes inference and writes back results to storage
• Storage challenges:
  • companion evaluation phase is blocked by cross-DC I/O
  • initialization phase is bottlenecked by an “I/O storm” where synchronous checkpoint loading triggers massive data contention on a small set of hot files
  • data loading shifts from being I/O-bound to compute-bound due to the high cost of transforming video and image data

Approach.

• Predictive checkpoint replication
  • Companion evaluations follow a predictable interval, typically every one thousand training steps; instead of issuing thousands of WAN reads for checkpoint shards, they are batched up and cached in the storage tier of the evaluation cluster.
  • Allow the storage scheduler to preempt background traffic to make room for high-priority evaluations.
• Proactive Hotspot Prediction
  • The training framework explicitly informs the storage system about upcoming access patterns
  • The storage tier only increases replication factor for hot metadata and replicated-parameter files
• Storage-Side Transformation Offloading
  • Multimodal data loading is compute-bound: the training hosts’ CPUs cannot decode video and images fast enough to keep the GPUs busy
  • A deterministic dataloader writes the exact order of upcoming samples into per-step files, so storage nodes know what comes next and use their spare CPUs to decode, crop and resize those samples just in time for the next step

Evaluation.

Reduce wasted GPU hours per evaluation from 16,800 to 4,000, shorten checkpoint loading time at each training start by 40.8%, and reduce training stalls caused by dataloading by 63.2%.

Food for thought.

This work is pretty solid and straightforward. ML workloads tend to be deterministic and that indicates room for prefetching and resource reservation.

Heterogeneous systems + AI storage systems are topics I should dive deeper into.

SBB: Eliminating Centralized Bottlenecks in Userspace Network Runtime

Kang Hu and Diyu Zhou (Peking University), with Zhongguancun Laboratory and Michigan Technological University · Paper · Code

• Network stack
• Kernel bypass

In one sentence.

SBB removes every centralized scheduler from a userspace network runtime: each core receives its own timer and NIC interrupts in user space through Intel’s User Interrupts (UINTR) and balances load itself, so throughput scales with the number of cores.

Background.

• Userspace network runtimes (Shinjuku, Caladan, etc.) must schedule three things, and every prior design centralizes at least one of them, which becomes the bottleneck as worker cores are added:
  • Request preemption: a central timer sends preemption signals (IPIs) to workers when a quantum expires
  • CPU allocation (lending idle cores to best-effort jobs): a central monitor polls every worker’s NIC queue for backlog, since a polling app that has given up its core cannot notice new packets
  • Request load balancing: RSS suffers from skewed flows; a dispatcher thread polling one NIC queue balances well but caps throughput
• Giving these components more cores doesn’t help: the authors measure worse load balancing and no gain elsewhere.

Approach.

• Each worker thread binds to a core with its own TX/RX queues and local timer, and schedules itself:
  • Preemption: before each request, the worker arms a one-shot APIC timer that interrupts into user space. With the timer registers mapped into user space, this costs ~50 cycles, versus ~3 µs for setitimer
  • CPU allocation: NIC interrupts replace polling. A running latency-critical thread takes them in its user-space handler; otherwise a kernel handler wakes it up, so idle cores can safely run best-effort jobs
  • Two-level load balancing: task stealing for temporary imbalance, and flow migration, which reprograms the NIC to move flows off overloaded cores, for persistent imbalance
• Both interrupts arrive at the same handler, so SBB enables them in disjoint phases: NIC interrupts only while waiting for packets (which also prevents interrupt storms), the timer only during application-layer work

Evaluation.

• Server: 2 NUMA nodes, each with a 64-core Intel Xeon Platinum 8592 at 1.9 GHz; 100 Gbps Intel E810 NIC
• Built on DPDK, plus a 2,095-line Linux kernel patch
• Baselines: Shinjuku, Concord and TQ for preemption; Skyloft and Caladan for CPU allocation
• SBB achieves 1.7× to 5.2× higher throughput at 48 cores, under the same tail latency target

Food for thought.

• UINTR control plane: the kernel is still involved, registering each core’s notification vector and the user-space handler (SBB also gives the NIC queue and APIC timer interrupts that vector).
• UINTR data path: the CPU first matches an incoming interrupt’s vector against the notification vector; on a match, it skips the IDT and runs the user-space handler directly, without entering ring 0.

Rakaia: Scalable In-Kernel Scheduling for TCP-Based RPCs

Rui Yang, Konstantinos Prasopoulos, and Edouard Bugnion, EPFL · Paper

• Network stack
• RPC

In one sentence.

For RPCs, the authors created a set of message semantic APIs based on kernel TCP/IP stack that removes extra I/O threads copying and head-of-line blocking.

Background.

• gRPC big picture:
  • NIC RX DMA into the memory, acked in device driver, handled over to TCP/IP stack
  • I/O threads were epoll waiting on the socket and wakes up when there is work. I/O threads call read which copies skbs into a userspace buffer, and parses the HTTP frames.
  • The complete message is enqueued to a global FIFO and handed to a worker.
• Bottlenecks:
  • TCP’s stream-oriented abstraction is a poor fit for message-oriented RPCs: RPCs sharing the same TCP stream are processed sequentially by default, causing HOL blocking
  • gRPC must reconstruct message semantics using additional userspace abstractions

Approach.

• Key insight:
  • message parsing and scheduling should occur in the same softirq context that processes incoming TCP packets.
  • messages must be decoupled from their underlying TCP connections to allow global scheduling
• Each application thread only needs a single Rakaia socket to handle all TCP traffic
  • Parsing the message from TCP byte stream in the same softirq context
  • Logical centralized queue of messages for scheduling
  • Work stealing on empty local queue for load balancing

Evaluation.

• Server: CloudLab xl170, one 10-core Intel Xeon E5-2640v4 at 2.4 GHz (20 hyperthreads); open-loop load over 20 to 5,000 connections, with 20 µs and 100 µs service times
• Achieves up to 5× higher throughputunder-SLO than KCM, Linux’s current in-kernel message API over TCP
• Improves gRPC-Go’s throughput-underSLO by up to 1.56×, and gRPC-C++’s by up to 2.69×
• Improves the throughput-under-SLO for real-world applications including Silo running TPC-C and OpenTelemetry Collector by 1.39× and 1.42×, respectively

Food for thought.

Thinking about Rakaia for UDP-based RPC systems and DPDK

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

The buddy allocator (post 6) hands out 4 KiB at a time, but a list node, a cache descriptor or a small buffer is a few dozen bytes. A slab allocator sits on top of it. It takes whole pages, cuts each into equal-size objects, and keeps one cache per object size. This post covers the slab layer (442dcfe) and kmalloc/kfree on top of it (fc88a1d), the last commit of this series.

ULK (ch. 8, “Memory Area Management”) describes Linux’s original SLAB allocator. It has cache descriptors, separate slab descriptors, per-object descriptor arrays, coloring and per-CPU caches, after Bonwick’s design for Solaris. toy-os is much smaller, and in two ways it is closer to SLUB, which replaced SLAB as Linux’s default: the slab’s bookkeeping lives in its struct page, and a free object itself holds the pointer to the next free object.

Table of Contents

• One struct page, three owners
• Caches and slabs
• Allocating and freeing objects
• kmalloc and kfree
• Watching it work
• What’s next
• References

One struct page, three owners

The slab commit adds three fields to struct page and one flag:

#define PG_reserved (1u << 0)
/* Set if it is the first page of a free block in buddy system */
#define PG_buddy (1u << 1)
/* Set on every page that is a slab, the slab fields below are valid */
#define PG_slab (1u << 2)
/* Set on the first page of a kmalloc too large for a slab, order holds its size */
#define PG_large (1u << 3)

struct page {
    uint16_t flags;
    uint16_t order;
    int32_t refcount;
    /* buddy: the free list of its order, slab: the partial list of its cache */
    struct list_head lru;
    /* PG_slab only, a slab is exactly one page so these describe the whole slab */
    struct kmem_cache *slab_cache;
    void *freelist;                 /* first free object, NULL when the slab is full */
    uint32_t inuse;                 /* objects handed out, 0 is empty, cache->objects is full */
};

The 28 bytes of struct page and who uses which field.

As my commit note says, lru is “shared” by the buddy and slab layers. A page cannot be free in the buddy system and hold objects in a slab at the same time, so the same list_head links free blocks in post 6 and partial slabs here. Linux’s struct page takes this much further, with unions of fields for every possible owner.

Caches and slabs

A cache is little more than a size and a list:

/* Example: struct kmem_cache "kmalloc-1024"
 * size = 1024, objects = 4
 * partial is a linked list whose container is struct page
 */
struct kmem_cache {
    const char *name;
    uint32_t size;
    uint32_t objects;
    /* Non-full slabs, slab = page frame here */
    struct list_head partial;
};

void kmem_cache_init(struct kmem_cache *cache, const char *name, uint32_t size, uint32_t align) {
    if (align == 0)
        align = sizeof(void *);
    ASSERT(is_pow2(align));
    ASSERT(size <= PAGE_SIZE && align <= PAGE_SIZE);

    size = ALIGN_UP(MAX(size, sizeof(void *)), align);

    cache->name = name;
    cache->size = size;
    cache->objects = PAGE_SIZE / size;
    INIT_LIST_HEAD(&cache->partial);
}

A slab is exactly one page. Every object is at least pointer-sized, because a free object stores the pointer to the next free object in its first 4 bytes. new_slab takes a page from the buddy system and threads that list through it. It walks backwards, so the list starts at object 0 and runs in address order:

/* Carve a fresh page */
static struct page *new_slab(struct kmem_cache *cache) {
    struct page *page = alloc_pages(0);
    char *base;

    if (!page)
        return NULL;

    base = page_address(page);
    page->freelist = NULL;
    /* Each slot either holds a valid obj or pointer to the next slot */
    /* As long as the slab is "partial", it's freelist is bound to point to a
     * free slot which should further point to its next free slot if possible
     */
    for (uint32_t i = cache->objects; i > 0; i--) {
        void **obj = (void **)(base + (i - 1) * cache->size);
        *obj = page->freelist;
        page->freelist = obj;
    }
    page->flags |= PG_slab;
    page->slab_cache = cache;
    page->inuse = 0;
    list_add(&page->lru, &cache->partial);
    return page;
}

The list costs no memory: free objects are unused memory anyway. Once objects are allocated and freed in random order, it no longer runs in address order:

One slab after four allocations and one free. The free list is a stack (LIFO).

Allocating and freeing objects

void *kmem_cache_alloc(struct kmem_cache *cache) {
    struct page *page;
    void **obj;

    if (list_empty(&cache->partial) && !new_slab(cache))
        return NULL;

    /* pop the head of the first partial slab's free list */
    page = list_first_entry(&cache->partial, struct page, lru);
    obj = page->freelist;
    page->freelist = *obj;
    page->inuse++;

    /* a full slab leaves the partial list, kmem_cache_free puts it back */
    if (page->inuse == cache->objects)
        /* Do not worry about losing track of full slabs, see kmem_cache_free() */
        list_del_init(&page->lru);
    return obj;
}

The cache tracks only partial slabs, the ones with at least one free object, so allocation never has to search. A full slab simply drops off the list. Nothing needs to find it until one of its objects is freed, and then the object’s address leads straight back to it: virt_to_page(obj) gives the page, and the page gives its cache.

void kmem_cache_free(struct kmem_cache *cache, void *obj) {
    struct page *page = obj_to_page(obj);

    ASSERT((page->flags & PG_slab) && page->slab_cache == cache);
    /* must be the start of an object, not a pointer into the middle of one */
    ASSERT(((uintptr_t)obj - (uintptr_t)page_address(page)) % cache->size == 0);
    /* a cheap double free check, it only catches freeing the last freed object again */
    ASSERT(page->inuse > 0 && obj != page->freelist);

    /* a full slab is about to have a free object, so it can serve allocations again */
    if (page->inuse == cache->objects)
        list_add(&page->lru, &cache->partial);

    /* push onto the free list */
    *(void **)obj = page->freelist;
    page->freelist = obj;
    page->inuse--;

    /* keep one slab even when empty, so allocating and freeing a single
     * object in a loop does not go to the buddy system every time */
    if (page->inuse == 0 && !list_is_singular(&cache->partial))
        free_slab(page);
}

Empty slabs go back to the buddy system (free_slab clears PG_slab, then calls free_pages). The exception is a cache’s last slab. Without that exception, a loop of kmalloc(32)/kfree would split and merge a buddy block on every iteration.

kmalloc and kfree

kmalloc picks one of nine caches, kmalloc-8 to kmalloc-2048, by rounding the size up to a power of two. Anything bigger goes straight to the buddy allocator:

/* index of the smallest kmalloc cache holding size bytes, 0 < size <= KMALLOC_MAX_CACHE_SIZE */
static inline uint32_t kmalloc_index(uint32_t size) {
    if (size <= (1u << KMALLOC_MIN_SHIFT))
        return 0;
    /* 32 - clz(size - 1) is log2 of size rounded up to a power of 2 */
    return 32 - __builtin_clz(size - 1) - KMALLOC_MIN_SHIFT;
}

void *kmalloc(size_t size) {
    struct page *page;
    uint32_t order;

    if (size == 0 || size > KMALLOC_MAX_SIZE)
        return NULL;
    if (size <= KMALLOC_MAX_CACHE_SIZE)
        return kmem_cache_alloc(&kmalloc_caches[kmalloc_index(size)]);

    /* too large for a slab: a buddy block of its own, its first page
     * remembers the order so kfree knows how much to give back */
    order = get_order(size);
    page = alloc_pages(order);
    if (!page)
        return NULL;
    page->flags |= PG_large;
    page->order = order;
    return page_address(page);
}

There is no kmalloc-4096. A 4 KiB object would fill a whole page, and a page is what the buddy allocator already hands out. A size of 2049 bytes still costs a whole page, which is the price of power-of-two classes. Every object is aligned to its size (up to PAGE_SIZE), since a slab starts on a page boundary and objects are packed at multiples of the size.

kfree gets only a pointer. The page’s flags say where it came from, and that is the point of PG_large. As my commit note says, it is cheap and lets kmalloc and kfree pair up:

void kfree(const void *ptr) {
    struct page *page;
    uint32_t order;

    if (!ptr)
        return;

    /* the page says which kind of kmalloc it was */
    page = obj_to_page(ptr);
    if (page->flags & PG_slab) {
        kmem_cache_free(page->slab_cache, (void *)ptr);
        return;
    }

    ASSERT((page->flags & PG_large) && ptr == page_address(page));
    order = page->order;
    page->flags &= ~PG_large;
    page->order = 0;
    free_pages(page, order);
}

The two paths through kmalloc, and how kfree finds the right one.

The checks catch a lot: a pointer below 0xC0000000 or beyond RAM, a pointer into the middle of an object, a page that is neither a slab nor a large allocation, and freeing the same object twice in a row. My commit note also records what they miss. A wrong pointer that happens to land on the start of another object passes every check, and that object is freed while someone still uses it. Linux catches that class of bug with KASAN, which keeps shadow memory to track whether each byte may be accessed.

kmem_cache_create() makes a cache for a specific object type. The struct kmem_cache itself (20 bytes) comes from kmalloc, in this case from kmalloc-32.

Watching it work

main() at fc88a1d only calls init_kmalloc(). To see the allocator at work, add a throwaway test after it (it is not part of the commit):

static void kmalloc_demo(void) {
    char *a = kmalloc(24);
    char *b = kmalloc(24);
    char *c = kmalloc(100);
    char *big = kmalloc(5000);

    printk("kmalloc(24)   = %p\n", a);
    printk("kmalloc(24)   = %p\n", b);
    printk("kmalloc(100)  = %p\n", c);
    printk("kmalloc(5000) = %p\n", big);
    kfree(b);
    printk("kfree(%p), then kmalloc(20) = %p\n", b, kmalloc(20));
}

The test’s output. Every address can be predicted from the free lists in post 6.

1. kmalloc(24) rounds up to kmalloc-32, which has no slab yet. new_slab asks for an order-0 page, and the order-0 list holds exactly one: pfn 0x500, the page left over from the loader’s tables. Object 0 is at 0xC0500000.
2. kmalloc(24) again pops object 1 from the same slab, 32 bytes later: 0xC0500020.
3. kmalloc(100) goes to kmalloc-128, which needs a new slab. The order-0 list is now empty, so the buddy allocator splits the order-1 block at 0x582. It returns 0x582 and puts 0x583 on the order-0 list. Result: 0xC0582000.
4. kmalloc(5000) is too big for a slab: get_order(5000) = 1, two pages. The order-1 list is empty after step 3, so the order-2 block at 0x584 splits into 0x584 (returned) and 0x586 (back on the order-1 list). That is the split pictured in post 6. Result: 0xC0584000, with PG_large and order = 1 on its first page.
5. kfree(b) then kmalloc(20): b goes back on the head of its slab’s free list, and the next kmalloc-32 allocation gets it right back, 0xC0500020. The most recently freed object is the most likely to still be in the CPU cache.

All of these are direct-map addresses: physical = virtual − 0xC0000000, and each allocation is physically contiguous. That is what DMA buffers and page tables need, but it is also the weakness of kmalloc. Once physical memory fragments, a large kmalloc fails even when there is plenty of free memory in total.

What’s next

That is where this series stops (fc88a1d). The commits after it give the kernel vmalloc (virtually contiguous memory built from single pages, with unmapped guard pages between areas), threads with vmalloc’ed kernel stacks, and a double-fault task gate that catches kernel stack overflows. They may become the next worklogs.

References

1. D. P. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd ed., ch. 8 “Memory Management”, “Memory Area Management”: the slab allocator, cache and slab descriptors, general and specific caches, and kmalloc().
2. J. Bonwick, “The Slab Allocator: An Object-Caching Kernel Memory Allocator”, USENIX Summer 1994 Technical Conference.
3. J. Corbet, “The SLUB allocator”, LWN.net, 2007; Linux source mm/slub.c.
4. The Linux kernel documentation, Kernel Address Sanitizer (KASAN).
5. navi, 从零开始写 OS 内核 - 实现堆和 malloc, segmentfault. It builds a heap allocator instead of slabs, a useful contrast.
6. 郑钢, 《操作系统真相还原》, ch. 12 (进一步完善内核): the book’s sys_malloc, built on arenas of 16–1024-byte blocks.

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

So far the kernel lives inside the first MiB, and the only other memory it knows about is the loader’s page tables. Bochs gives it 512 MiB. To hand out page frames, the kernel needs four things, in this order:

1. What RAM exists: the BIOS’s E820 map, collected by the loader in real mode.
2. A boot-time allocator to place its own data structures before any real allocator exists (memblock).
3. Page tables that map all of RAM, so that any frame can be reached through a pointer.
4. A struct page for every frame, and the buddy allocator on top of them.

That is the order of main() (with the work spread over commits cbd7402, 8625d4f, 7a8ec84, cd46473 and ab8312c):

    /* GDT's memory is safely pre-allcoated in BSS section, under _end */
    /* But kernel PG and PTs are phys_mem_alloc()ed already */
    e820_probe_phys_mem();
    init_pd();
    // Hand over physical pages to zone
    init_page_alloc();

The design follows Linux as ULK describes it (ch. 8, “Page Frame Management”), cut down to one zone.

Table of Contents

• E820: asking the BIOS
• memblock: a boot-time allocator
• Kernel page tables for all of RAM
• struct page and mem_map
• The buddy system
• Physical memory after init_page_alloc()
• References

E820: asking the BIOS

int 0x15 with EAX = 0xE820 returns the memory map one entry per call. The caller passes EDX = 'SMAP', an entry size in ECX, a buffer in ES:DI, and a continuation value in EBX (0 the first time). The BIOS hands back the next EBX, and EBX = 0 means that was the last entry. Each entry is a 64-bit base, a 64-bit length and a 32-bit type (1 usable, 2 reserved, 3 ACPI reclaimable, 4 ACPI NVS, 5 bad). This is a BIOS call, so the loader does it in real mode, before anything else (post 3):

; Store the BIOS E820 memory map at MEM_MAP_ADDR (layout in boot.inc)
detect_memory:
    mov dword [MEM_MAP_COUNT_ADDR], 0
    ; es:di = where the BIOS writes the next entry
    mov di, MEM_MAP_ENTRIES_ADDR
    ; continuation value, 0 = start from the first entry
    xor ebx, ebx
.next_entry:
    mov eax, 0xe820
    ; 'SMAP', set on every call since some BIOSes trash edx
    mov edx, 0x534d4150
    mov ecx, MEM_MAP_ENTRY_SIZE
    int 0x15
    ; cf set: no E820 on the first call, end of list on later ones
    jc .done
    ; eax = 'SMAP' confirms the BIOS understood the call
    cmp eax, 0x534d4150
    jne .done
    ; skip entries with a 0 qword length at offset 8
    mov eax, [di + 8]
    or eax, [di + 12]
    jz .skip
    inc dword [MEM_MAP_COUNT_ADDR]
    add di, MEM_MAP_ENTRY_SIZE
    ; stop before the map grows into the loader's stack
    cmp dword [MEM_MAP_COUNT_ADDR], MEM_MAP_MAX_ENTRIES
    jae .done
.skip:
    ; ebx = 0: that was the last entry
    test ebx, ebx
    jnz .next_entry

The map goes to physical 0x500: a dword count, then up to 32 entries of 20 bytes, ending at 0x784, just below the loader at 0x800 (post 1). Dumping it in Bochs right after the call:

<bochs> xp /28wx 0x500
0x0000000000000500 <bogus+       0>:	0x00000005	0x00000000	0x00000000	0x0009f000
0x0000000000000510 <bogus+      16>:	0x00000000	0x00000001	0x0009f000	0x00000000
0x0000000000000520 <bogus+      32>:	0x00001000	0x00000000	0x00000002	0x000e8000
0x0000000000000530 <bogus+      48>:	0x00000000	0x00018000	0x00000000	0x00000002
0x0000000000000540 <bogus+      64>:	0x00100000	0x00000000	0x1ff00000	0x00000000
0x0000000000000550 <bogus+      80>:	0x00000001	0xfffc0000	0x00000000	0x00040000
0x0000000000000560 <bogus+      96>:	0x00000000	0x00000002	0x00000000	0x00000000

All 4 GiB of physical address space according to E820 (not to scale).

Two things to notice. First, the map only lists ranges, so holes such as [0xA0000, 0xE8000) (video memory, VGA ROM) are simply absent, and so is everything between 512 MiB and the BIOS ROM. Second, entry 4 ends at 0x1_0000_0000, which wraps to 0 in 32 bits. e820_probe_phys_mem therefore computes in 64 bits and clips to the last page boundary that fits in a uint32_t:

        // 64 bit: the BIOS area entry 0xfffc0000 + 0x40000 = 0x100000000 wraps to 0 in 32 bits
        uint64_t start64 = ((uint64_t)entry->base_addr_high << 32) | entry->base_addr_low;
        uint64_t end64 = start64 + (((uint64_t)entry->length_high << 32) | entry->length_low);
        ...
        if (entry->type != E820_ARDS_TYPE_Memory || start64 >= PHYS_ADDR_LIMIT) {
            continue;
        }
        ...
        uint32_t entry_start = ALIGN_UP((uint32_t)start64, PAGE_SIZE);
        uint32_t entry_end = ALIGN_DOWN((uint32_t)end64, PAGE_SIZE);

        block_list_add(&ards_mem, entry_start, entry_end);

Only type 1 ranges are kept, rounded inward to whole pages, since a partial page cannot be handed out.

memblock: a boot-time allocator

The page tables and mem_map need memory before the page allocator exists. Linux solves this with memblock (older kernels used a bitmap-based bootmem allocator): two sorted lists of physical ranges, memory and reserved. A boot-time allocation is a first fit in “memory minus reserved”, and allocating just means adding a reserved range. toy-os does the same with two fixed arrays:

/* ascending and non-overlapping */
struct phys_mem_list {
    struct phys_mem_block blocks[PHYS_MEM_MAX_BLOCKS];
    uint32_t count;
};

/* usable RAM from E820, filled once by e820_probe_phys_mem and never changed after */
static struct phys_mem_list ards_mem;
/* free mem = ards_mem - ards_rsved, will only be used once */
static struct phys_mem_list ards_rsved;

• block_list_add inserts [start, end) and merges it with every block it overlaps or touches.
• block_list_remove trims a block’s head or tail, deletes a fully covered block, or splits a block in two.
• phys_mem_alloc(size, align) tries aligned candidates in each usable block. When a candidate overlaps a reserved block, it jumps past that block and tries again.
• phys_mem_for_each_free(fn) walks both sorted lists in step and calls fn on each free gap. That is how everything ends up in the buddy allocator below.

Right after probing, two ranges are reserved. The first is everything below max(1 MiB, _end): the kernel, the BIOS areas, the dead loader and buffer, the stack. The second is the loader’s page tables at [0x100000, 0x501000) (post 3). They touch, so the list merges them into one block. Commit 8625d4f printed the lists:

dump_phys_mem() at commit 8625d4f. The 5 E820 entries became 2 usable blocks.

max_pfn = 0x20000 is one past the highest usable page frame number: 131072 frames of 4 KiB = 512 MiB.

Kernel page tables for all of RAM

The loader’s tables map only the first MiB. To reach any frame through a C pointer, the kernel maps all RAM at 0xC0000000, the way Linux’s direct mapping (“low memory”) does. For 512 MiB that takes 128 page tables plus one page directory:

void init_pd(void) {
    uint32_t n_pts = DIV_ROUND_UP(max_pfn, PT_ENTRIES);
    uint32_t first_pde = PD_INDEX(KERNEL_OFFSET);

    if (first_pde + n_pts > PD_ENTRIES) {
        PANIC("%u MiB of RAM does not fit the kernel's 1 GiB of address space",
            max_pfn >> (20 - PAGE_SHIFT));
    }

    /* Create a new kernel page dir, not colliding with loader's */
    kernel_pd = early_alloc(PAGE_SIZE);
    kernel_pts = early_alloc(n_pts * PAGE_SIZE);
    memset(kernel_pd, 0, PAGE_SIZE);
    memset(kernel_pts, 0, n_pts * PAGE_SIZE);

    for (uint32_t pfn = 0; pfn < max_pfn; pfn++) {
        kernel_pts[pfn] = mk_pte(pfn << PAGE_SHIFT, PG_KERNEL);
    }
    for (uint32_t i = 0; i < n_pts; i++) {
        kernel_pd[first_pde + i] = mk_pde(virt_to_phys(&kernel_pts[i * PT_ENTRIES]), PG_KERNEL);
    }

    /* no identity map of low memory, so virtual 0 faults, and no recursive entry:
     * page tables are reached through the direct map from here on */
    asm volatile ("mov %0, %%cr3" : : "r"(virt_to_phys(kernel_pd)) : "memory");

    /* the CPU no longer walks the loader's page directory and page tables, give them back */
    phys_mem_free(LOADER_PAGE_TABLES_START, LOADER_PAGE_TABLES_END);
}

There is a chicken-and-egg problem. phys_mem_alloc returns 0x501000, the first free byte, but the CPU still walks the loader’s tables, which map nothing above 1 MiB. So memset(kernel_pd, ...) at 0xC0501000 would page-fault. early_alloc maps each new frame first, by writing a PTE into the loader’s tables through the recursive window from post 3:

/* A brief recap of loader pt mapping:
 * PD starts at 0x100000, PTs start at 0x101000
 * PDE 0 and both PDE 768 point to PT0, which covers the first 1 MB
 * PDE 769 - 1022 are mapped to PT 769 - 1022, but PTEs are empty
 * PDE 1023 points to PD
 */
#define LOADER_PTES ((pte_t *)0xFFC00000)

/* Mapping kernel_pd and kernel_pts virtual addr, for later arr + index access */
static void *early_alloc(uint32_t size) {
    uint32_t phys = phys_mem_alloc(size, PAGE_SIZE);
    ...
    for (uint32_t off = 0; off < size; off += PAGE_SIZE) {
        uint32_t va = (uint32_t)phys_to_virt(phys + off);
        /* All PTs (arry of PTEs) are packed */
        LOADER_PTES[va >> PAGE_SHIFT] = mk_pte(phys + off, PG_KERNEL);
        asm volatile ("invlpg (%0)" : : "r"(va) : "memory");
    }
    return phys_to_virt(phys);
}

VA 0xC0501000 falls under PDE 769, and the loader created PT 769 in advance (empty), exactly for cases like this. As my commit note says, adding the new tables to the loader’s tables makes their virtual addresses valid, which saves working with physical addresses. Two details:

• kernel_pts is one contiguous 512 KiB array, so the PTE for frame pfn is simply kernel_pts[pfn].
• The flags are PG_KERNEL: present and writable, without the user bit the loader used.

After mov cr3, Bochs sees a single mapping:

cr3: 0x000000501000
0x00000000c0000000-0x00000000dfffffff -> 0x000000000000-0x00001fffffff

The kernel page directory: one direct map, nothing else. Compare with the loader’s six mappings in post 3.

The identity map is gone, so a NULL pointer dereference now page-faults, and the fault handler from post 5 names it. The recursive entry is gone too: page tables are now ordinary memory in the direct map. The PANIC in init_pd marks this design’s limit. With more than 1 GiB of RAM, the direct map would not fit in the kernel’s 1 GiB of virtual space. Linux stops its direct map at 896 MiB to keep 128 MiB free for vmalloc and temporary mappings, and treats the rest as high memory (ULK ch. 8). toy-os has no high memory.

struct page and mem_map

The buddy allocator needs a descriptor for every page frame: struct page, in one array called mem_map, indexed by page frame number (pfn):

struct page {
    uint16_t flags;
    uint16_t order;
    int32_t refcount;
    /* buddy: the free list of its order, slab: the partial list of its cache */
    struct list_head lru;
    /* PG_slab only, a slab is exactly one page so these describe the whole slab */
    struct kmem_cache *slab_cache;
    void *freelist;                 /* first free object, NULL when the slab is full */
    uint32_t inuse;                 /* objects handed out, 0 is empty, cache->objects is full */
};

extern struct page *mem_map;
#define pfn_to_page(pfn) (mem_map + (pfn))
#define page_to_pfn(page) ((uint32_t)((page) - mem_map))
#define page_address(page) phys_to_virt(page_to_phys(page))
#define virt_to_page(va) pfn_to_page(virt_to_phys(va) >> PAGE_SHIFT)

In the buddy commit it was 16 bytes: flags, order, refcount and lru. The slab fields arrive in post 7, which makes it 28 bytes, and 131072 × 28 B = 3.5 MiB:

void init_page_alloc(void) {
    uint32_t size = max_pfn * sizeof(struct page);
    uint32_t phys = phys_mem_alloc(size, PAGE_SIZE);
    ...
    mem_map = phys_to_virt(phys);

    /* every frame starts reserved: holes, the kernel, page tables and mem_map itself
     * must never be handed out, only usable minus reserved is freed below */
    for (uint32_t pfn = 0; pfn < max_pfn; pfn++) {
        struct page *page = pfn_to_page(pfn);
        page->flags = PG_reserved;
        ...
    }
    ...
    /* memblock is not used after this, from here on frames come from alloc_pages */
    phys_mem_for_each_free(free_range);
}

phys_mem_alloc returns 0x100000 this time. init_pd has just freed the loader’s page tables, so mem_map moves into the first free spot: the old page tables. It has to be in the direct map (all of RAM is), because it is reached through a pointer.

The buddy system

The buddy system keeps free memory in blocks of 2^order pages, order 0 to MAX_ORDER = 10 (4 KiB to 4 MiB). Every block is aligned to its own size, and there is one free list per order:

/* Number of free blocks, not pages */
struct free_block {
    struct list_head free_list;
    uint32_t nr_free;
};

#define MAX_ORDER 10

/* Order = pow(2, order) number of pages */
struct zone {
    struct free_block free_blocks[MAX_ORDER + 1];
    uint32_t free_pages;
};

Only the first page of a free block is on a list. It carries PG_buddy, and its order field records the block size. The list link is lru, so the free lists take no memory of their own.

Who is my buddy?

The commit’s note lists three rules for two blocks to be buddies:

1. They have the same order.
2. They are next to each other in physical memory.
3. The lower one is aligned to 2^order+1 pages, so together they form a valid block one order up.

Rules 2 and 3 mean the buddy of the block at pfn differs from pfn in exactly one bit, bit order. Flipping it gives the buddy:

/* Flipping the bit is a clever trick! */
static struct page *neigh_buddy(struct page *page, uint32_t order) {
    uint32_t buddy_pfn = page_to_pfn(page) ^ (1u << order);
    return buddy_pfn < max_pfn ? pfn_to_page(buddy_pfn) : NULL;
}

static void free_one_page(struct page *page, uint32_t order) {
    while (order < MAX_ORDER) {
        struct page *buddy = neigh_buddy(page, order);

        if (!buddy || !(buddy->flags & PG_buddy) || buddy->order != order)
            break;
        remove_from_zone(buddy, order);
        /* the merged block starts at the lower half */
        if (buddy < page)
            page = buddy;
        order++;
    }
    add_to_zone(page, order);
}

The test PG_buddy && order == order covers rule 1: the buddy must be the head of a free block of the same size, not, say, the middle of a larger free block, or a page in use. Linux’s __free_one_page does the same with page_is_buddy().

Allocation goes the other way. It takes the smallest non-empty order that is big enough, and while the block is too big, it splits it and puts the upper half back on the list one order down:

struct page *alloc_pages(uint32_t order) {
    for (uint32_t o = order; o <= MAX_ORDER; o++) {
        struct free_block *free_block = &zone.free_blocks[o];
        if (list_empty(&free_block->free_list))
            continue;

        struct page *page = list_first_entry(&free_block->free_list, struct page, lru);
        remove_from_zone(page, o);
        while (o > order) {
            o--;
            add_to_zone(page + (1u << o), o);
        }
        page->refcount = 1;
        zone.free_pages -= (1u << order);
        return page;
    }
    return NULL;
}

A split and a merge, with the real pfns kmalloc(5000) uses in post 7.

free_pages checks what it can before giving a block back: the order is in range, the pfn is aligned to it, the page is not reserved, not already free, and not owned by the slab layer or kmalloc, and the refcount is exactly 1.

Filling the free lists

At boot, each free range from memblock goes through free_range, which carves it into the largest aligned blocks that fit:

/* Only those page frames entirely contained are reclaimed */
static void free_range(uint32_t start, uint32_t end) {
    uint32_t pfn = PFN_UP(start);
    uint32_t end_pfn = PFN_DOWN(end);

    while (pfn < end_pfn) {
        /* __builtin_ctz = count trailing zeros */
        uint32_t order = pfn ? MIN((uint32_t)__builtin_ctz(pfn), MAX_ORDER) : MAX_ORDER;
        while (pfn + (1u << order) > end_pfn)
            order--;
        for (uint32_t i = 0; i < (1u << order); i++)
            pfn_to_page(pfn + i)->flags &= ~PG_reserved;
        zone.free_pages += (1u << order);
        free_one_page(pfn_to_page(pfn), order);
        pfn += 1u << order;
    }
}

The number of trailing zero bits of pfn is the largest order it is aligned to. The inner loop shrinks the block until it fits in what is left. Starting from pfn 0x582 (...0010), that gives order 1, then 0x584 order 2, 0x588 order 3, and so on, up to 0x800, where order 10 takes over. The comment and my third commit note point out the limit of PFN_UP/PFN_DOWN: a range that starts or ends in the middle of a page loses that partial page. With E820 entries and reservations that are all page aligned, nothing is lost here.

I read the resulting free lists straight out of zone in the Bochs debugger. The struct addresses on the lists convert back to pfns:

zone.free_blocks after init_page_alloc(). list_add inserts at the head, so the last block freed, the highest, comes first.

Physical memory after init_page_alloc()

The final physical layout. Everything white is now in the buddy allocator. memblock’s reserved list ends as [0, 0x480000) and [0x501000, 0x582000).

131072 frames − 256 (low MiB) − 896 (mem_map) − 129 (page tables) = 129791 free pages, which is exactly what the kernel prints:

The second line on the screen.

The page allocator only hands out whole pages, though, and most kernel objects are a few dozen bytes. Post 7 builds slab caches and kmalloc on top of it.

References

1. D. P. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd ed., ch. 8 “Memory Management”: page descriptors, memory zones, high memory, and “The Buddy System Algorithm”. Also ch. 2, “Paging in Linux”: the kernel’s final page tables and the 896 MiB limit.
2. 郑钢, 《操作系统真相还原》, ch. 5 (获取物理内存容量: E820, E801 and 88h) and ch. 8 (内存管理系统). The book manages memory with bitmaps; toy-os follows Linux here.
3. navi, 从零开始写 OS 内核 - 虚拟内存完善, segmentfault.
4. Linux source: mm/memblock.c, and __free_one_page() and __find_buddy_pfn() in mm/page_alloc.c.
5. OSDev Wiki, Detecting Memory (x86).

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

The kernel prints (post 4), but it runs with IF = 0, the way the loader left it, and it has no IDT. A divide by zero would end in a triple fault and a reboot. This post adds the Interrupt Descriptor Table, a common entry path for all 256 vectors, the 8259A interrupt controller and a 100 Hz timer. (These were the commits 18ae789, 14a9b9a and 4a3564b.)

Table of Contents

• Vectors
• The IDT
• 256 stubs and one common path
• A first test: int3
• The 8259A PIC
• The PIT and a 100 Hz tick
• PANIC turns interrupts off first
• References

Vectors

Every interrupt or exception arrives as a vector number, 0–255:

• 0–31: CPU exceptions. Intel reserves all of them, defined or not. Examples: 0 divide error, 3 breakpoint, 6 invalid opcode, 8 double fault, 13 general protection, 14 page fault. Some of them (8, 10–14, 17, 21) push an error code on the stack. The others do not.
• External interrupts come from devices through an interrupt controller, which the OS programs to use vectors of its choosing. toy-os uses 0x20–0x2F.
• Software interrupts: int n raises vector n. int3 (one byte, 0xCC) is the breakpoint.

Most exceptions are either faults, where the saved EIP points at the instruction that faulted so it can be retried (page fault), or traps, where it points at the next instruction (int3). A few are aborts (double fault, machine check), which cannot be resumed at all.

The IDT

The IDT works like the GDT (post 2): a table of 8-byte descriptors, found through a register, IDTR. Each entry is a gate that holds a selector:offset pointing at the handler:

The gate for vector 0x20, as Bochs’s info idt decodes it below.

/* With only Interrupt Gate Descriptors, nested interrupts cannot happen
 * Trap Gate Descriptors does not clear IF so interrupts are not masked
 */
struct interrupt_descriptor {
    uint16_t offset_15_0;
    uint16_t segment_selector;
    uint8_t zero;
    uint8_t type_attr;
    uint16_t offset_31_16;
} __attribute__((packed));

/* P = 1, DPL = 00b, Type = 1110b */
#define INTER_DESC_TYPE_DEFAULT 0x8E

void init_idt(void) {
    for (int i = 0; i < IDT_SIZE; i++) {
        idt[i].offset_15_0 = intr_stubs[i] & 0xFFFF;
        /* Index + TI + DPL */
        idt[i].segment_selector = 0b1000;
        idt[i].zero = 0;
        idt[i].type_attr = INTER_DESC_TYPE_DEFAULT;
        idt[i].offset_31_16 = intr_stubs[i] >> 16;
    }
    struct idt_ptr idtr;
    idtr.limit = sizeof(idt) - 1;
    idtr.base = (uint32_t)idt;
    asm volatile ("lidt %0" : : "m" (idtr));
}

All 256 gates are 32-bit interrupt gates. Entering one clears IF, so a handler cannot be interrupted, and nesting is impossible for now. A trap gate (type 1111) would leave IF alone. The table is 2 KiB of .bss at 0xC0007E20:

<bochs> info idt 0 4
Interrupt Descriptor Table (base=0x00000000c0007e20, limit=2047):
IDT[0x00]=32-Bit Interrupt Gate target=0x0008:0xc0004780, DPL=0
IDT[0x01]=32-Bit Interrupt Gate target=0x0008:0xc0004789, DPL=0
IDT[0x02]=32-Bit Interrupt Gate target=0x0008:0xc0004792, DPL=0
...
<bochs> info idt 32 34
IDT[0x20]=32-Bit Interrupt Gate target=0x0008:0xc0004890, DPL=0
IDT[0x21]=32-Bit Interrupt Gate target=0x0008:0xc0004899, DPL=0

Two privilege checks, from my notes on the commit (ULK ch. 4 walks through them):

1. The handler’s code segment DPL must be ≤ CPL. A handler can never be less privileged than the code it interrupts. All gates use selector 0x08, the ring 0 kernel code, so this always passes.
2. For a software interrupt (int n, int3, into), CPL ≤ gate DPL, or the CPU raises #GP instead. Every gate here has DPL 0, so a ring 3 program cannot int 0x20 and pretend to be the timer. A system call gate will be the one gate with DPL 3. Hardware interrupts and CPU exceptions skip this check.

256 stubs and one common path

The CPU tells the handler nothing about which vector brought it there, and only some exceptions push an error code. So each vector gets a tiny stub that makes the stack look the same every time. nasm’s %rep writes all 256:

%define HAS_ERRCODE(v) ((v) == 8 || ((v) >= 10 && (v) <= 14) || (v) == 17 || (v) == 21)

section .text

%assign vec 0
%rep 256
stub_%[vec]:
; If this vec has no err code, push placeholder
%if !HAS_ERRCODE(vec)
    push 0
%endif
    push vec
    jmp intr_common
%assign vec vec + 1
%endrep

intr_common:
    ; Predefined order: eax, ecx, edx, ebx, esp, ebp, esi, edi
    pushad
    push esp
    cld
    call intr_dispatch
    add esp, 4
    popad
    ; the err code/placeholder + the vec
    add esp, 8
    iretd

section .rodata
intr_stubs:
%assign vec 0
%rep 256
    dd stub_%[vec]
%assign vec vec + 1
%endrep

A stub is 9 bytes (push 0, push imm8, jmp rel32). The 8 vectors with an error code skip push 0 and take 7. That explains the IDT targets above: 0xC0004780 + 24 × 9 + 8 × 7 = 0xC0004890 for vector 0x20. intr_stubs is the table of stub addresses that init_idt copies into the gates.

When intr_dispatch starts, the stack holds a complete frame. push esp passes its address as the argument, and the C struct below describes it:

Who pushes what. user_esp and user_ss are only there when the interrupt came from ring 3, which cannot happen yet.

struct intr_frame {
    uint32_t edi, esi, ebp, esp_dummy, ebx, edx, ecx, eax;
    uint32_t vector, err_code;
    uint32_t eip, cs, eflags;
    uint32_t user_esp, user_ss;
};

The cld matters. The C calling convention guarantees the direction flag is clear when a function is called, but an interrupt can arrive in the middle of code that set it, such as a backwards rep movsb. Without cld, any memcpy in a handler would run backwards.

The C side is a table of function pointers, plus a fallback that names the exception and halts:

void intr_dispatch(struct intr_frame *f) {
    /* Fall thru APIC vector range */
    if (f->vector >= PIC_IRQ_BASE && f->vector < PIC_IRQ_BASE + PIC_IRQ_COUNT) {
        if (!pic_ack(f->vector - PIC_IRQ_BASE)) {
            return;
        }
    }

    if (intr_handlers[f->vector]) {
        intr_handlers[f->vector](f);
    } else {
        unhandled_intr(f);  // "exception 13 (general protection), err 0x..., eip 0x..."
    }
}

A first test: int3

static void on_breakpoint(struct intr_frame *f) {
    printk("int3 at eip %#x\n", f->eip);
}
...
    register_handler(3, on_breakpoint);
    asm volatile ("int $3");
    printk("back from int3\n");

It prints int3 at eip 0xc0001815, yet int3 itself is at 0xC0001814:

c0001814:	int3
c0001815:	sub    $0xc,%esp

int3 is a trap, so the saved EIP is the next instruction, and iretd resumes there: “back from int3”. A debugger that patches 0xCC over an instruction has to back EIP up by one to re-run it.

The 8259A PIC

Device interrupts go through two Intel 8259A chips. The master takes IRQ 0–7. The slave takes IRQ 8–15 and signals the master on the master’s IRQ 2. The CPU sees one interrupt line (INTR), asks the PIC for a vector, and goes through the IDT:

From a device to a C handler and back.

The BIOS leaves the master on vectors 0x08–0x0F. Those are CPU exceptions in protected mode: an untouched timer IRQ 0 would arrive as vector 8, a “double fault”. So the first job is to remap both chips, with four initialization command words (ICW) each:

void init_pic(void) {
    /* ICW1 on the command port, ICW2-4 then follow on the data port */
    outb(PIC_MASTER_CMD, ICW1_INIT_ICW4);   // 0x11: init, cascaded, edge, ICW4 follows
    outb(PIC_SLAVE_CMD, ICW1_INIT_ICW4);

    /* ICW2: vector of the chip's IRQ 0, the low 3 bits must be 0 */
    outb(PIC_MASTER_DATA, PIC_IRQ_BASE);        // 0x20
    outb(PIC_SLAVE_DATA, PIC_IRQ_BASE + 8);     // 0x28

    /* ICW3: the master gets a bitmask of the pins with a slave on them,
     * the slave gets the number of the master pin it hangs off */
    outb(PIC_MASTER_DATA, 1 << IRQ_CASCADE);
    outb(PIC_SLAVE_DATA, IRQ_CASCADE);

    outb(PIC_MASTER_DATA, ICW4_8086);       // 8086 mode, EOI sent by software
    outb(PIC_SLAVE_DATA, ICW4_8086);

    /* OCW1: mask everything but the cascade, drivers unmask their own IRQ */
    outb(PIC_MASTER_DATA, (uint8_t)~(1 << IRQ_CASCADE));
    outb(PIC_SLAVE_DATA, 0xFF);
}

(The real code has an io_wait(), a write to the unused POST port 0x80, after each ICW, because real 8259As need a moment between them.)

After delivering an IRQ, the PIC holds back IRQs of equal or lower priority until it gets an end-of-interrupt (EOI, 0x20 on the command port). An IRQ from the slave is in service on both chips, so both need an EOI. intr_dispatch sends it before calling the handler. That is safe because the interrupt gate has cleared IF: a new IRQ can be raised at the PIC but will not reach the CPU before iretd.

pic_ack also catches spurious IRQs. If a device drops its line before the CPU acknowledges it, the PIC still has to answer with a vector, so it hands out its lowest-priority one: IRQ 7 (master) or 15 (slave). It does not mark it in service, though, so reading the in-service register tells the two apart:

int pic_ack(uint8_t irq) {
    if (irq == 7 || irq == 15) {
        uint16_t cmd = irq == 7 ? PIC_MASTER_CMD : PIC_SLAVE_CMD;
        outb(cmd, OCW3_READ_ISR);
        if (!(inb(cmd) & 0x80)) {
            /* The master did see the cascade IRQ 2, only the slave's was fake */
            if (irq == 15) {
                outb(PIC_MASTER_CMD, OCW2_EOI);
            }
            return 0;
        }
    }
    /* An IRQ from the slave is in service on both chips */
    if (irq >= 8) {
        outb(PIC_SLAVE_CMD, OCW2_EOI);
    }
    outb(PIC_MASTER_CMD, OCW2_EOI);
    return 1;
}

The PIT and a 100 Hz tick

The 8253/8254 programmable interval timer counts down from a divisor at 1.193182 MHz. In mode 2 (rate generator), channel 0 raises IRQ 0 every time it reaches zero and reloads:

#define PIT_INPUT_HZ 1193182
/* Channel 0 (bits 7-6 = 00), low byte then high byte (bits 5-4 = 11),
 * mode 2 rate generator (bits 3-1 = 010), binary count (bit 0 = 0) */
#define PIT_CMD_CH0_RATE 0x34

/* volatile: an IRQ changes it behind the back of any loop reading it */
static volatile uint32_t ticks;

static void on_timer(struct intr_frame *f) {
    (void)f;
    ticks++;
    if (ticks % TIMER_HZ == 0) {
        printk("uptime %u s\n", ticks / TIMER_HZ);
    }
}

void init_timer(void) {
    uint16_t divisor = PIT_INPUT_HZ / TIMER_HZ;     // 11931, i.e. 100.007 Hz

    outb(PIT_CMD, PIT_CMD_CH0_RATE);
    outb(PIT_CHANNEL0, divisor & 0xFF);
    outb(PIT_CHANNEL0, divisor >> 8);

    register_handler(PIC_IRQ_BASE + IRQ_TIMER, on_timer);
    pic_unmask(IRQ_TIMER);
}

Then, for the first time since the loader’s cli in post 3:

    init_timer();
    /* IF has been 0 since the loader's cli, IRQs only arrive from here on */
    asm volatile ("sti");
    for (;;) {
        /* sleep until the next interrupt instead of spinning */
        asm volatile ("hlt");
    }

The kernel at commit 14a9b9a, stopped after the fifth “uptime” line. main was at 0xC0001520 back then.

PANIC turns interrupts off first

The next commit (4a3564b) added PANIC and ASSERT. My note on it: interrupts need to be disabled before PANIC.

/* cli first: with IF set, the next IRQ wakes hlt and its handler keeps
 * printing over the panic message */
#define PANIC(...) do { \
    asm volatile ("cli"); \
    printk("PANIC at %s:%d %s(): ", __FILE__, __LINE__, __func__); \
    printk(__VA_ARGS__); \
    printk("\n"); \
    for (;;) { \
        asm volatile ("hlt"); \
    } \
} while (0)

hlt only sleeps until the next interrupt. With IF still set, the timer would wake the CPU 100 times a second, on_timer would print “uptime” lines under (and eventually over) the panic message, and the system would look half-alive. With cli, hlt really is the end; only an NMI could wake it.

main still has an ASSERT(1 == 2) right after sti, as a test. In the current build the compiler knows the assertion always fails, so sti is followed directly by cli:

c000182a:	sti
c000182b:	cli
c000182c:	push   $0xc00062b0

sti only takes effect after the next instruction, which is cli. So no tick ever gets in, and the screen ends like this:

toy-os at fc88a1d, the end of this series. The “page allocator” line comes from post 6.

References

1. 郑钢, 《操作系统真相还原》, ch. 7 (中断): the IDT, the 8259A, interrupt stubs with error-code placeholders, and the 8253 timer.
2. navi, 从零开始写 OS 内核 - 中断处理, segmentfault.
3. D. P. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd ed., ch. 4 “Interrupts and Exceptions”: IRQs and the PIC, the IDT, the hardware’s privilege checks, and why Linux sets most gates to DPL 0.
4. Intel 64 and IA-32 Architectures Software Developer’s Manual, Vol. 3A, “Interrupt and Exception Handling”: the exception table, error codes, gate descriptors, and the interrupt shadow of sti.
5. OSDev Wiki, 8259 PIC (including spurious IRQs) and Programmable Interval Timer.

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

Paging is on and the loader runs in protected mode with a stack at 0xC009F000 (post 3). The last thing it does is start the kernel. The kernel is written in C and built as an ordinary ELF executable. An ELF file is not a memory image, though, so the loader has to read the file’s program headers and lay out the memory itself.

Table of Contents

• Building the kernel
• Reading kernel.bin from the disk
• Copying the segments
• Physical memory when main() starts
• First words from C: VGA and printk
• References

Building the kernel

CFLAGS := -m32 -ffreestanding -nostdinc -Iinclude \
          -fno-pie -fno-stack-protector -fno-asynchronous-unwind-tables \
          -Wall -Wextra -MMD -MP

kernel.bin: $(KERNEL_OBJS)
	ld -m elf_i386 $^ -Ttext 0xc0001500 -e main -o $@

• -m32, -m elf_i386: 32-bit code and a 32-bit ELF.
• -ffreestanding -nostdinc: there is no C library and no host headers. include/ has its own stdint.h, stdarg.h and string.h.
• -fno-pie: the kernel is linked at a fixed address and nothing will relocate it.
• -fno-stack-protector: otherwise gcc emits canary checks. On i386 the canary is read from %gs:0x14, a thread-local slot that does not exist here.
• -fno-asynchronous-unwind-tables: no .eh_frame, since nothing will ever unwind the stack.
• -Ttext 0xc0001500 -e main: .text starts at 0xC0001500, and the ELF entry point is main.

Why 0xC0001500? 0xC0000000 + PA 0x1500 puts the kernel in the higher half, in low memory just above the loader (0x800–0xFFF). As my commit note says, ld decides the target virtual addresses, and the ELF program headers record them:

$ readelf -l kernel.bin
Entry point 0xc00017b4
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0xc0001000 0xc0000000 0x000d4 0x000d4 R   0x1000
  LOAD           0x000500 0xc0001500 0xc0001500 0x03cd3 0x03cd3 R E 0x1000
  LOAD           0x005000 0xc0006000 0xc0006000 0x00d6c 0x00d6c R   0x1000
  LOAD           0x005d6c 0xc0007d6c 0xc0007d6c 0x00004 0x010a8 RW  0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00
   01     .text
   02     .rodata
   03     .data .bss

• With 4 KiB alignment, a segment’s file offset and virtual address must be equal modulo 4 KiB. .text at 0xC0001500 therefore sits at file offset 0x500. The first page of the file, 0xC0001000, holds only the ELF header and program headers: segment 00, 212 bytes.
• The entry point 0xC00017B4 is not the start of .text. gdt.o comes first in the link order, and -e main just records main’s address.
• The last segment has FileSiz 4 but MemSiz 0x10A8: that is .bss. It takes up memory but has no bytes in the file.

Reading kernel.bin from the disk

Before paging (post 3), the loader reads 200 sectors from LBA 9 to a buffer at 0x70000. It uses the same ATA PIO routine as the MBR (post 1), rewritten with 32-bit registers:

    ; load kernel.bin into a buffer, it is an ELF file so its code is not at offset 0
    mov eax, KERNEL_START_SECTOR    ; 9
    mov ebx, KERNEL_BIN_BASE_ADDR   ; 0x70000
    mov ecx, KERNEL_SECTOR_COUNT    ; 200
    call read_disk

200 sectors is 100 KiB, so the buffer is [0x70000, 0x89000). Today kernel.bin is 34,272 bytes (67 sectors). KERNEL_SECTOR_COUNT must match count=200 in the Makefile, and the kernel file must stay under 100 KiB, or its tail is silently cut off. The first bytes of the buffer show the ELF magic:

<bochs> xp /16bx 0x70000
0x0000000000070000 <bogus+       0>:	0x7f	0x45	0x4c	0x46	0x01	0x01	0x01	0x00
0x0000000000070008 <bogus+       8>:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00

Copying the segments

kernel_init walks the program header table and handles each PT_LOAD entry. The offsets are those of Elf32_Ehdr and Elf32_Phdr:

kernel_init:
    ...
    ; e_phentsize, namely program header size
    mov dx, [KERNEL_BIN_BASE_ADDR + 42]
    ; e_phoff, offset of the first program header
    mov ebx, [KERNEL_BIN_BASE_ADDR + 28]
    ; e_phnum, number of program header
    mov cx, [KERNEL_BIN_BASE_ADDR + 44]

    add ebx, KERNEL_BIN_BASE_ADDR

.each_segment:
    ; p_type is a dword, only PT_LOAD segments get copied into memory
    cmp dword [ebx], PT_LOAD
    jne .next_segment

    ; memcpy from bin to the designated place
    push dword [ebx + 16]           ; p_filesz
    mov eax, [ebx + 4]              ; p_offset
    add eax, KERNEL_BIN_BASE_ADDR
    push eax
    push dword [ebx + 8]            ; p_vaddr
    call mem_cpy
    add esp, 12

    ; .bss takes memory but no file bytes (p_memsz > p_filesz), zero
    ; the tail so C globals start at 0
    mov eax, [ebx + 20]
    sub eax, [ebx + 16]
    push eax                        ; p_memsz - p_filesz
    mov eax, [ebx + 8]
    add eax, [ebx + 16]
    push eax                        ; p_vaddr + p_filesz
    call mem_zero
    add esp, 8

.next_segment:
    add ebx, edx
    loop .each_segment
    ret

The file layout (offsets from 0x70000) and the memory layout it turns into. The bands are the four mem_cpy calls.

The p_vaddr addresses are above 0xC0000000. That works because paging is on and PDE 768 maps VA 0xC0000000–0xC00FFFFF to the first MiB. As my commit note says, this loader pays for an extra copy: disk → buffer → final place. A smarter loader would read the headers first and then read each segment straight from the disk to its address.

The .bss zeroing was not there at first. It came with printk (c91a8c0), whose cursor_x and cursor_y were the first C globals that had to start at 0.

Then the jump:

    call kernel_init

    mov esp, KERNEL_STACK_TOP       ; 0xC009F000
    ; e_entry
    jmp [KERNEL_BIN_BASE_ADDR + 24]

The kernel stack is the loader’s stack, reset to its top: the loader’s frames are simply forgotten. At the first instruction of main:

(0) Breakpoint 7, 0x00000000c00017b4 in ?? ()
(0) [0x0000000017b4] 0008:00000000c00017b4 (unk. ctxt): lea ecx, ss:[esp+4]       ; 8d4c2404
rsp: 00000000_c009f000
rip: 00000000_c00017b4

Physical memory when main() starts

This is the whole first MiB, plus what lies above it, at the first instruction of main:

Physical memory at main(). Amber regions are done and could be reused. The whole first MiB is also visible at VA 0xC0000000 + PA.

A few things follow from this layout:

• The kernel image overwrites the MBR (0x7C00–0x7DFF), which is fine, since the MBR is long dead. The kernel’s GDT (post 2) ends up exactly in the MBR’s last 128 bytes.
• In memory, the kernel can grow up to the buffer at 0x70000, about 444 KiB. The file is the tighter limit: 100 KiB.
• Nothing here is reclaimed yet. Post 6 simply reserves the whole first MiB. With a kernel of about 32 KiB, that is simpler than tracking every gap.
• kernel.h turns the higher-half rule into two macros, valid for anything in the kernel half:

/* the kernel half starts here, physical address p is at KERNEL_OFFSET + p */
#define KERNEL_OFFSET 0xC0000000
#define phys_to_virt(x) ((void *)((uintptr_t)(x) + KERNEL_OFFSET))
#define virt_to_phys(x) ((uintptr_t)(x) - KERNEL_OFFSET)

First words from C: VGA and printk

The first main (bf3a03a) was just while(1);. Once that ran without faulting, the next commit (c91a8c0) gave the kernel a voice.

The text buffer

In 80 × 25 color text mode, each screen cell is two bytes in the buffer: the character, then an attribute.

One cell. The kernel prints white on black, attribute 0x0F.

src/vga.c writes cells at 0xC00B8000, keeps its own cursor, scrolls by copying rows 1–24 up one row, and moves the hardware cursor through the CRTC registers:

/* 0xB8000 seen through the kernel alias the loader maps at 0xC0000000 */
#define VIDEO_SEG_BASE 0xc00b8000

void put_char(char c, uint8_t color) {
    uint16_t *video_memory = (uint16_t *)VIDEO_SEG_BASE;

    if (c == '\n') {
        cursor_x = 0;
        cursor_y++;
    } else if (c == '\r') {
        cursor_x = 0;
    } else {
        // char is signed, without the cast bytes >= 0x80 sign-extend over the color
        video_memory[cursor_y * VGA_WIDTH + cursor_x] = (color << 8) | (uint8_t)c;
        cursor_x++;
    }
    ...
}

The comment marks a real trap. char is signed on x86, so a byte like 0xB0 becomes 0xFFB0 when promoted to int. OR’ed with color << 8, that wipes out the attribute byte.

printk and varargs

printk is a thin wrapper: vformat() in lib/stdio.c parses the format and calls a putc callback for each character. It supports %d %i %u %o %x %X %c %s %p %%, the flags - + space # 0, width and precision (* too), and the length modifiers hh h l z.

static void vga_putc(char c, void *arg) {
    (void)arg;
    put_char(c, VGA_COLOR_DEFAULT);
}

/* Characters go straight to the screen, so no buffer limits the length */
int printk(const char *format, ...) {
    va_list ap;
    int len;

    va_start(ap, format);
    len = vformat(vga_putc, NULL, format, ap);
    va_end(ap);
    return len;
}

With -nostdinc there is no <stdarg.h>, but varargs are a compiler feature anyway. include/stdarg.h just names the builtins:

typedef __builtin_va_list va_list;
#define va_start(ap, last) __builtin_va_start(ap, last)
#define va_arg(ap, type) __builtin_va_arg(ap, type)
#define va_end(ap) __builtin_va_end(ap)

On i386, __builtin_va_list is just a char * into the caller’s stack frame. The cdecl caller pushes the arguments right to left, so in memory they sit left to right above the return address:

c00017d2:	push   $0xc00017b4      ; 2nd argument: main
c00017d7:	push   $0xc0006241      ; 1st argument: the format string
c00017dc:	call   c0001adf <printk>

va_start(ap, format) points ap just past format. Each va_arg(ap, int) reads 4 bytes and moves on. Arguments narrower than int (char, short) are promoted to int when passed, which is why vformat reads %hhd as (signed char)va_arg(ap, int).

main clears the screen and prints its own address: %p of main = e_entry.

The kernel can talk now, but it cannot listen: any exception would still take the machine down. Post 5 adds an IDT, the 8259A PIC and a timer.

References

1. 郑钢, 《操作系统真相还原》, ch. 5 (加载内核: ELF, the kernel at 0xc0001500, the 0x70000 buffer) and ch. 6 (完善内核: printing to the screen).
2. navi, 从零开始写 OS 内核 - 加载并进入 kernel and 显示与打印, segmentfault.
3. man 5 elf: Elf32_Ehdr and Elf32_Phdr.
4. System V Application Binary Interface, Intel386 Architecture Processor Supplement: the cdecl calling convention and variable argument lists.
5. OSDev Wiki, Text UI and Text Mode Cursor.

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

The loader at 0x800 has a GDT (post 2). It now does five things, in this order:

1. Ask the BIOS for the memory map (E820). BIOS calls only work in real mode, so this comes first (post 6 covers it).
2. Switch to 32-bit protected mode.
3. Read kernel.bin from the disk into a buffer (post 4).
4. Build page tables and turn on paging, moving itself into the higher half at 0xC0000000.
5. Copy the kernel into place and jump to it (post 4).

This post covers steps 2 and 4.

Table of Contents

• Into protected mode
• Why paging
• The loader’s page tables
• Turning paging on and moving to the higher half
• The virtual address space now
• The recursive entry
• References

Into protected mode

loader_entry:
    ; BIOS calls only work in real mode, collect the memory map first
    call detect_memory

    ; disable interrupts - no IDT yet, any interrupt in prot mode would triple fault
    cli

    ; enable A20
    in al, 0x92
    or al, 0000_0010b
    out 0x92, al

    ; load GDT
    lgdt [GDT_PTR]

    ; open protection mode - set cr0 bit 0
    mov eax, cr0
    or eax, 0x00000001
    mov cr0, eax

    ; refresh pipeline
    jmp dword SELECTOR_CODE:prot_mode_entry

• cli. In protected mode, interrupts go through an IDT, and there is none yet (post 5). The real-mode vector table at address 0 means nothing to a protected-mode CPU. The first timer tick would fault, the fault could not be delivered either (double fault), and then the CPU resets (triple fault). IF stays 0 until the kernel runs sti in post 5.
• A20. The 8086 wrapped addresses at 1 MiB, and some old software relied on it, so PCs keep address line 20 forced to 0 until someone enables it. With A20 off, every odd MiB is an alias of the even one below it: 0x100000 reads 0x000000. Setting bit 1 of port 0x92 (the “fast A20” gate) turns it on.
• lgdt, then CR0.PE = 1.
• The far jump. Setting PE does not change how the CPU runs the next instruction. CS still holds the descriptor it cached in real mode, and instructions that were already fetched and decoded as 16-bit code are still in the pipeline. A far jump loads CS from GDT entry 1 and discards that prefetched code. dword makes it a 48-bit selector:offset32 pointer: 66 EA 22 09 00 00 08 00.

Bochs makes the in-between state visible. Here are the segment registers right after mov cr0, eax and before the jump, at 0x8A3:

(0) [0x0000000008a3] 0000:00000000000008a3 (unk. ctxt): jmpf 0x0008:00000922      ; 66ea220900000800
cs:0x0000, dh=0x00009300, dl=0x0000ffff, valid=1
	Data segment, base=0x00000000, limit=0x0000ffff, Read/Write, Accessed
gdtr:base=0x0000000000000803, limit=0x1f
CR0=0x60000011: pg CD NW ac wp ne ET ts em mp PE

PE is set, yet CS is still the 64 KiB real-mode segment. One instruction later, at prot_mode_entry:

(0) [0x000000000922] 0008:0000000000000922 (unk. ctxt): mov ax, 0x0010            ; 66b81000
cs:0x0008, dh=0x00cf9b00, dl=0x0000ffff, valid=1
	Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, Accessed, 32-bit

The new code then reloads the other segment registers from the GDT and gets a stack:

[bits 32]
prot_mode_entry:
    ; segment registers still hold real-mode values, reload with selectors
    mov ax, SELECTOR_DATA
    mov ds, ax
    mov es, ax
    mov ss, ax
    mov esp, LOADER_STACK_TOP       ; 0x9F000
    mov ax, SELECTOR_VIDEO
    mov gs, ax

Without the BIOS, printing means writing character/attribute pairs straight into the text buffer through gs. The cursor position also has to be done by hand: it lives in two CRTC registers, index 0x0E (high byte) and 0x0F (low byte), behind ports 0x3D4/0x3D5. print_prot_mode reads the position the BIOS left there, writes the string from that point, handles CR and LF, and writes the new position back, so the protected-mode lines continue right under the MBR’s.

Why paging

With flat segments (post 2), segmentation protects nothing. Paging gives every 4 KiB page its own mapping and its own permission bits (present, writable, user). That is what lets a kernel:

• live at the same virtual addresses in every process (Linux on 32-bit x86: user space 0–0xBFFFFFFF, kernel 0xC0000000 and up),
• keep user code out of kernel memory, and
• use physical memory wherever it happens to be free.

32-bit x86 paging with 4 KiB pages uses two levels. CR3 holds the physical address of a page directory (1024 four-byte PDEs). Each PDE points to a page table (1024 PTEs), and each PTE points to a 4 KiB page frame. A virtual address is split into 10, 10 and 12 bits:

Translating VA 0xC00B8140, the text buffer seen through the kernel alias, with the loader’s real table contents.

A PDE, 0x00101007. The low 12 bits are flags, because tables and frames are 4 KiB aligned.

The loader’s page tables

The loader puts the page directory at 1 MiB, the first address above the BIOS areas:

PAGE_DIR_BASE equ 0x100000
PAGE_TABLE_0_BASE equ 0x101000
PDE_FLAGS equ ...       ; U/S | R/W | P = 0x7
PTE_FLAGS equ ...       ; same
PDE_0 equ PAGE_TABLE_0_BASE + PDE_FLAGS
PTE_0 equ PAGE_0_BASE + PTE_FLAGS

setup_gpt:
    xor eax, eax
PURGE_LEN equ (1024 * 4 + 1024 * 1024 * 4)
.purge_mem:
    mov byte [PAGE_DIR_BASE + eax], 0
    inc eax
    cmp eax, PURGE_LEN
    jl .purge_mem

    ; Setting up PDE0 and PT0
    mov dword [PAGE_DIR_BASE], PDE_0
    mov dword [PAGE_DIR_BASE + 768 * 4], PDE_0

    xor eax, eax
    ; PTE for frame 0, advanced one frame per entry
    mov ebx, PTE_0

; Map the first 1M of memory
; VA [0x0, 0x100000) and VA[0xc0000000, 0xc0100000) map to PA [0x0, 0x100000)
.setup_pt0:
    mov dword [PAGE_TABLE_0_BASE + 4 * eax], ebx
    add ebx, 4096
    inc eax
    cmp eax, 256
    jl .setup_pt0

    ; Recursive Mapping of Page Directory
    mov dword [PAGE_DIR_BASE + 1023 * 4], PAGE_DIR_BASE + PDE_FLAGS

; Map other kernel PDEs
    mov ecx, 769
    mov ebx, PAGE_TABLE_0_BASE + 769 * 4096 + PDE_FLAGS
.setup_kernel_pdes:
    mov dword [PAGE_DIR_BASE + ecx * 4], ebx
    add ebx, 4096
    inc ecx
    cmp ecx, 1023
    jl .setup_kernel_pdes
    ret

The page directory gets four kinds of entries:

• PDE 0 → PT0 and PDE 768 → PT0. PT0 maps frames 0–255, the first MiB. The same 1 MiB appears twice: at VA 0 (identity), so the loader keeps running after paging is on, and at VA 0xC0000000 (768 × 4 MiB), where the kernel will live.
• PDE 769–1022 → their own page tables, all of whose PTEs are zero. Nothing is mapped there yet, but every kernel PDE already exists. A future process’s page directory can copy PDEs 768–1023 once, and the whole kernel half is shared from then on. Post 6 also relies on PDE 769 being there.
• PDE 1023 → the page directory itself, the recursive entry (below).

The page table for PDE i sits at 0x101000 + i × 4 KiB. That needs no allocator, but it leaves slots 1–768 empty: 3 MiB of zeroed, never-used memory. Here is the physical side:

Physical memory taken by the loader’s paging structures: [0x100000, 0x501000), 4 MiB + 4 KiB. Post 6 gives it back.

Zeroing that region byte by byte costs four instructions per byte. Bochs counts 7,348,009 instructions when setup_gpt is called and 24,144,543 at the magic breakpoint after paging is on. The difference, 16.8 million, is almost exactly 4 × PURGE_LEN (4,198,400 bytes). So two thirds of all instructions before the kernel starts go into this one loop. rep stosd would be four times fewer iterations. It does not matter in Bochs, but it is a fun number.

The flags are 0x7: present, writable and user. With U/S = 1 everywhere, ring 3 code could read and write the kernel. That is harmless while nothing runs in ring 3, and the kernel’s own page tables (post 6) drop the user bit.

Turning paging on and moving to the higher half

    call setup_gpt

; Move GDT, video segment and stack to their kernel aliases
    sgdt [GDT_PTR]
    ; video desc base 31..24 is the top byte of its high dword: 0xB8000 -> 0xC00B8000
    or dword [VIDEO_DESC + 4], 0xC0000000
    ; GDTR base 0x803 -> 0xC0000803
    add dword [GDT_PTR + 2], 0xC0000000
    add esp, 0xC0000000

; Enable paging
    mov eax, PAGE_DIR_BASE
    mov cr3, eax
    ; set cr0 bit 31 (PG)
    mov eax, cr0
    or eax, 0x80000000
    mov cr0, eax

    ; GDTR base is a linear address, load the high one only after paging is on
    lgdt [GDT_PTR]
    ; gs still caches the old video base until the selector is reloaded
    mov ax, SELECTOR_VIDEO
    mov gs, ax

The idea, as my commit note puts it: mirror the stack pointer and video segment to kernel space after paging. Everything the CPU finds by linear address has to move to its alias above 0xC0000000, because the identity map will not last (post 6 removes it):

• The GDTR base is a linear address. After paging, the GDT is still reachable at 0x803 through the identity map, but the kernel should not depend on that. The new base, 0xC0000803, is loaded with lgdt only once paging is on. Before that, 0xC0000803 would be a physical address, and there is no RAM there.
• The video segment base: 0xB8000 → 0xC00B8000. Base bits 31..24 are the top byte of the descriptor’s high dword, so a single or does it. gs must then be reloaded, or it keeps the base it cached earlier (post 2).
• The stack: esp += 0xC0000000. This happens before paging is on, when 0xC009F000 points at nothing. It works because nothing touches the stack between the add and mov cr0, eax: no push, no call.

Why does execution survive mov cr0, eax at all? The next instruction’s address is still around 0x990, and the identity map (PDE 0) translates it to the same physical address. Without PDE 0, the very next fetch would page-fault, with no IDT to handle it.

At the magic breakpoint (xchg bx, bx) right after this:

gs:0x0018, dh=0xc0c0930b, dl=0x80000007, valid=7
	Data segment, base=0xc00b8000, limit=0x00007fff, Read/Write, Accessed
gdtr:base=0x00000000c0000803, limit=0x1f
CR0=0xe0000011: PG CD NW ac wp ne ET ts em mp PE
CR3=0x000000100000

The last line is written through gs with base 0xC00B8000, so it went through the page tables.

The virtual address space now

info tab in Bochs lists every mapping in the current page tables:

cr3: 0x000000100000
0x0000000000000000-0x00000000000fffff -> 0x000000000000-0x0000000fffff
0x00000000c0000000-0x00000000c00fffff -> 0x000000000000-0x0000000fffff
0x00000000ffc00000-0x00000000ffc00fff -> 0x000000101000-0x000000101fff
0x00000000fff00000-0x00000000fff00fff -> 0x000000101000-0x000000101fff
0x00000000fff01000-0x00000000ffffefff -> 0x000000402000-0x0000004fffff
0x00000000fffff000-0x00000000ffffffff -> 0x000000100000-0x000000100fff

The loader’s virtual address space (left) and where it lands in physical memory (right). Hatched = no mapping; touching it is a page fault.

The first two lines are the double mapping of the first MiB. The other four all come from one entry, PDE 1023.

The recursive entry

PDE 1023 points at the page directory itself. A PDE and a PTE have the same format, so the CPU happily uses the directory as if it were a page table. For any VA in the top 4 MiB, 0xFFC00000–0xFFFFFFFF:

1. The PD index is 1023, so the “page table” is the page directory.
2. The PT index i picks PDE i, so the “page frame” is page table i.

So the top 4 MiB is a window onto all the page tables, laid out in PDE order, and the last page of it, PT index 1023, is the directory itself. The comment in loader.S works through VA 0xFFC00001: PD index 1023 → the PD; PT index 0 → PDE 0 → PT0 at 0x101000; offset 1 → byte 1 of PT0.

The top 4 MiB through PDE 1023. It matches the last four lines of info tab.

As my commit note says, this trick only works because PDEs and PTEs share the same format. It lets code edit a page table by virtual address without knowing where the table sits physically. Two formulas give the entry for any VA:

pte_t *pte = (pte_t *)(0xFFC00000 + (va >> 12) * 4);
pde_t *pde = (pde_t *)(0xFFFFF000 + (va >> 22) * 4);

The kernel uses the first one exactly once, in post 6, to map the frames of its new page tables before it switches to them.

Post 4 is the last thing the loader does: copy the kernel’s ELF segments to 0xC0001000 and jump to main.

References

1. 郑钢, 《操作系统真相还原》, ch. 4 (进入保护模式: A20, CR0.PE, flushing the pipeline) and ch. 5 (启用内存分页机制: page directory at 1 MiB, the kernel at 3 GiB, PDE 1023 pointing at the directory).
2. navi, 从零开始写 OS 内核 - GDT 与保护模式 and 虚拟内存初探, segmentfault.
3. D. P. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd ed., ch. 2 “Memory Addressing”: “Paging in Hardware” (regular paging) and “Paging in Linux” (the kernel’s 3 GiB / 1 GiB split).
4. Intel 64 and IA-32 Architectures Software Developer’s Manual, Vol. 3A, “Paging”: 32-bit paging, PDE and PTE formats.
5. OSDev Wiki, A20 Line.

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

The loader at 0x800 (post 1) wants to leave real mode. In protected mode a segment register no longer holds address / 16. It holds a selector, an index into a table of descriptors that the OS writes in memory. So before setting CR0.PE, the loader needs that table: the Global Descriptor Table (GDT). This post covers the GDT. Post 3 does the actual switch.

Table of Contents

• Visible and hidden parts of a segment register
• Selectors
• Descriptors
• The loader’s GDT
• Flat segments, like Linux
• The kernel’s own GDT
• References

Visible and hidden parts of a segment register

Each segment register (cs, ds, es, fs, gs, ss) has a 16-bit visible part, the selector, and a hidden part, the descriptor cache: base, limit and access rights. When a selector is loaded (mov ds, ax, or a far jump for cs), the CPU reads the descriptor from the table, checks it, and copies it into the cache. Every later memory access uses the cache, not the table.

Bochs’s sreg prints both. In the line below, dh and dl are the two dwords of the cached descriptor:

cs:0x0008, dh=0x00cf9b00, dl=0x0000ffff, valid=1
	Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, Accessed, 32-bit

Post 1 already showed the hidden part at work: at reset, CS has selector 0xF000 but base 0xFFFF0000. In real mode a selector load sets base = selector × 16. In protected mode the base comes from the descriptor.

The CPU turns a logical address (selector:offset) into a linear address in three steps:

1. Find the descriptor: index × 8 into the table that GDTR points at.
2. Check the offset against the limit, and the access against the type and privilege. A failed check raises #GP.
3. Linear address = base + offset. Paging is still off, so linear = physical.

Here is one real access. The loader’s print_prot_mode writes mov [gs:ebx * 2], ax. For the first character of row 2 of the screen, ebx * 2 = 0x140:

A logical address through the loader’s GDT. The CPU actually reads the descriptor once, when gs is loaded, not on every access.

Selectors

A selector. With TI = 0 and RPL = 0 it is simply the byte offset of the descriptor in the GDT.

boot.inc builds the three selectors the loader uses:

SELECTOR_CODE equ (1 << SELECTOR_DESC_IDX_OFFSET) + \
                  (0b << SELECTOR_TI_OFFSET) + \
                  (00b << SELECTOR_RPL_OFFSET)
SELECTOR_DATA equ (2 << SELECTOR_DESC_IDX_OFFSET) + ...
SELECTOR_VIDEO equ (3 << SELECTOR_DESC_IDX_OFFSET) + ...

Index 0 must be the null descriptor. Loading selector 0 into ds is allowed (it marks the register unusable), but any access through it faults.

Descriptors

A descriptor is 8 bytes. The layout is odd because of history: the 80286 had 24-bit bases and 16-bit limits, and the 386 squeezed the missing high bits into the word the 286 had left reserved.

The loader’s code descriptor, 0x00CF9A00_0000FFFF.

• Base (32 bits, in three pieces) and limit (20 bits, in two). With G = 1 the limit counts 4 KiB units, so 0xFFFFF means the whole 4 GiB.
• D/B = 1: a 32-bit segment (default operand size and esp for stacks).
• P = 1: present. DPL: the privilege level the descriptor belongs to (0 = kernel, 3 = user).
• S = 1: a code or data segment. With S = 0 it would be a system descriptor, such as a TSS or a gate.
• Type for code is X C R A: executable, not conforming, readable, accessed = 1010. For data it is X E W A: not executable, expands up, writable = 0010. The CPU sets A when it loads the descriptor, which is why Bochs shows dh=0x00cf9b00 (type 1011).

Instead of a magic 0x00CF9A00, boot.inc composes each field with a shift:

; -------- Code segment --------
; Base: 0, Limit: 0xFFFFF * 4K = 4G
; Type: x=1,c=0,r=1,a=0
DESC_CODE_HIGH_32 equ (0 << DESC_BASE_31_24_OFFSET) + \
                      (1 << DESC_G_OFFSET) + \
                      (1 << DESC_DB_OFFSET) + \
                      (0 << DESC_L_OFFSET) + \
                      (0 << DESC_AVL_OFFSET) + \
                      (1111b << DESC_LIMIT_19_16_OFFSET) + \
                      (1 << DESC_P_OFFSET) + \
                      (00b << DESC_DPL_OFFSET) + \
                      (1 << DESC_S_OFFSET) + \
                      (1010b << DESC_TYPE_OFFSET) + \
                      (0 << DESC_BASE_23_16_OFFSET)

DESC_CODE_LOW_32 equ (0 << DESC_BASE_15_0_OFFSET) + \
                     (0xFFFF << DESC_LIMIT_15_0_OFFSET)

The loader’s GDT

The table lives inside loader.bin, right after its first instruction:

section loader vstart=LOADER_BASE_ADDR
jmp loader_entry

; temporary gdt to enter protection mode
GDT_BASE:
RESV_DESC:
    dd 0x0
    dd 0x0
CODE_DESC:
    dd DESC_CODE_LOW_32
    dd DESC_CODE_HIGH_32
DATA_DESC:
    dd DESC_DATA_LOW_32
    dd DESC_DATA_HIGH_32
VIDEO_DESC:
    dd DESC_VIDEO_LOW_32
    dd DESC_VIDEO_HIGH_32
GDT_SIZE equ $ - GDT_BASE
GDT_LIMIT equ GDT_SIZE - 1

; lgdt 48-bit
GDT_PTR:
    dw GDT_LIMIT
    dd GDT_BASE

jmp loader_entry assembles to 3 bytes (E9 87 00), so in memory:

lgdt [GDT_PTR] copies those 6 bytes into GDTR. The table itself stays where it is: the CPU reads it from memory every time a selector is loaded. At the first protected-mode instruction (0x922, post 3), Bochs shows:

gdtr:base=0x0000000000000803, limit=0x1f
gdt (base=0x0000000000000803, limit=31):
gdt[0x0000]=<null entry>
gdt[0x0008]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, Accessed, 32-bit
gdt[0x0010]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write
gdt[0x0018]=Data segment, base=0x000b8000, limit=0x00007fff, Read/Write

The video descriptor is the only interesting one. Its base is 0xB8000 and its limit is 0x0007 with G = 1, so the limit is (7 + 1) × 4 KiB − 1 = 0x7FFF: 32 KiB, exactly the color text buffer 0xB8000–0xBFFFF. A write through gs past the buffer raises #GP instead of scribbling over the VGA BIOS ROM. That limit check is the only real protection segmentation gives toy-os.

What each of the loader’s segments can reach.

Flat segments, like Linux

Code and data are flat: base 0, limit 4 GiB. Translation does nothing, offset = linear address, and a C pointer is just a linear address. ULK (ch. 2, “Segmentation in Linux”) describes Linux doing the same. Its four main segments, __KERNEL_CS, __KERNEL_DS, __USER_CS and __USER_DS, all have base 0 and limit 2³² − 1. They differ only in type and DPL. ULK’s reasons are that memory management is simpler when every process uses the same linear addresses, and that RISC architectures barely support segmentation. Protection moves to paging (post 3). Segments are left with one job: their DPL decides whether the CPU runs at ring 0 or ring 3.

The kernel’s own GDT

The loader’s GDT has two problems. It lives inside loader.bin, which is dead once the kernel runs, and it has no user segments. In the revision commit (cbd7402), main() starts with init_gdt(), which builds a new table in the kernel’s .bss:

/* GDT indices, a selector is index << 3 | RPL
 * kernel code must stay at 1: the loader's cs and every IDT gate use selector 0x08 */
#define KERNEL_CODE_IDX 0x1
#define KERNEL_DATA_IDX 0x2
#define USER_CODE_IDX 0x3
#define USER_DATA_IDX 0x4

struct gdt_entry {
    uint16_t limit_low;
    uint16_t base_low;
    uint8_t base_middle;
    uint8_t access;
    uint8_t granularity;
    uint8_t base_high;
} __attribute__((packed));

static struct gdt_entry gdt[MAX_GDT_ENTRIES];
static struct gdtr gdtr;

void init_gdt(void) {
    gdt[0] = (struct gdt_entry){0};

    gdt[KERNEL_CODE_IDX].limit_low = 0xFFFF;
    gdt[KERNEL_CODE_IDX].access = 0x9A; // Present, Ring 0, Code Segment
    gdt[KERNEL_CODE_IDX].granularity = 0xCF; // 4K granularity, 32-bit
    ...
    gdtr.limit = sizeof(gdt) - 1;
    gdtr.base = (uint32_t)&gdt;

    // lgdt only changes where descriptors are read from, each segment register keeps
    // the descriptor it cached when loaded, so reload them all from the new table
    // cs can only be reloaded by a far jump
    asm volatile("lgdt %0\n\t"
                 "ljmp %1, $1f\n"
                 "1:\n\t"
                 "mov %2, %%ax\n\t"
                 "mov %%ax, %%ds\n\t"
                 "mov %%ax, %%es\n\t"
                 "mov %%ax, %%fs\n\t"
                 "mov %%ax, %%gs\n\t"
                 "mov %%ax, %%ss"
                 : : "m"(gdtr), "i"(KERNEL_CODE_SELECTOR), "i"(KERNEL_DATA_SELECTOR)
                 : "eax", "memory");
}

granularity = 0xCF is the high nibble G = 1, D/B = 1 and the low nibble limit bits 19:16 = 0xF. All four segments are flat, so they differ only in DPL and type, as in Linux. Index 3 used to be the video segment. The kernel’s VGA code now writes to 0xC00B8000 through the flat data segment, so gs becomes plain 0x10.

The lgdt comment is the important part. GDTR only says where descriptors are read from, and every segment register keeps the descriptor it cached when it was loaded. If cs and ss were not reloaded, they would keep pointing into the loader’s table, and that would only show up much later, as a fault the first time something reloads them. cs cannot be the target of a mov, hence the ljmp to the next line. Bochs right after init_gdt():

gdt (base=0x00000000c0007d80, limit=127):
gdt[0x0000]=<null entry>
gdt[0x0008]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, Accessed, 32-bit
gdt[0x0010]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
gdt[0x0018]=Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, 32-bit
gdt[0x0020]=Data segment, base=0x00000000, limit=0xffffffff, Read/Write
gdt[0x0028]=<null entry>
...
gs:0x0010, dh=0x00cf9300, dl=0x0000ffff, valid=1
	Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed

The table has 16 entries (limit = 16 × 8 − 1 = 127). The free ones are for later, such as a TSS. It sits at VA 0xC0007D80, which is physical 0x7D80–0x7DFF, the last 128 bytes of where the MBR was loaded in post 1. The kernel image has long since overwritten the MBR (post 4).

A word on privilege, which post 5 builds on. The low two bits of cs are the current privilege level (CPL). A selector carries a requested privilege level (RPL), and a descriptor its DPL. To load a data segment, the CPU requires max(CPL, RPL) ≤ DPL. Everything in toy-os runs at CPL 0 so far, so the checks always pass.

References

1. 郑钢, 《操作系统真相还原》, ch. 4 (保护模式入门): segment descriptors, the GDT, selectors.
2. navi, 从零开始写 OS 内核 - GDT 与保护模式 and 全局描述符表 GDT, segmentfault.
3. D. P. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd ed., ch. 2 “Memory Addressing”: “Segmentation in Hardware” and “Segmentation in Linux”.
4. Intel 64 and IA-32 Architectures Software Developer’s Manual, Vol. 3A, “Protected-Mode Memory Management”: segment selectors, segment descriptors, descriptor tables.

Toy OS worklog: 1. Real mode · 2. Segmentation · 3. Paging · 4. Kernel · 5. Interrupts · 6. Buddy · 7. Slab · Source

toy-os is a small 32-bit x86 kernel I am writing from scratch. I want to see what happens between power-on and a kernel that hands out memory, not just read about it. It runs in the Bochs emulator. The boot path follows 《操作系统真相还原》 and navi’s 从零开始写 OS 内核 series. For memory management I copy Linux’s design, as described in Understanding the Linux Kernel (ULK).

The source code is on GitHub: twicy/toy-os. These worklogs cover the code up to commit fc88a1d (2026-10-20), one milestone per post:

1. Real mode: from power-on through the BIOS to the MBR (this post)
2. Segmentation and the GDT
3. Protected mode and paging
4. Loading the kernel
5. Interrupts, the PIC and the timer
6. Physical memory: E820, memblock and the buddy system
7. Slab and kmalloc

Every address in these posts comes from the real thing: Bochs’s debugger, readelf, or the toy-os screen.

Table of Contents

• Setup
• Power-on: the first instruction
• The BIOS loads sector 0 to 0x7C00
• Real-mode addressing and the first MiB
• The MBR
• References

Setup

The tools:

• Bochs 2.8, with the bochs and bochs-x packages, 512 MiB of RAM and the legacy BIOS image (BIOS-bochs-legacy). The sound card needs sound: driver=dummy, and the keyboard is set with keyboard:, because the old keyboard_mapping: option is gone.
• nasm for the boot code, and later gcc -m32 and ld for the kernel (post 4).
• A flat disk image, toy-os.img, with 20 cylinders × 16 heads × 63 sectors. The Makefile writes each binary into it with dd.

dd if=./mbr.bin    of=./toy-os.img bs=512 count=1   conv=notrunc
dd if=./loader.bin of=./toy-os.img bs=512 count=4   seek=2 conv=notrunc
dd if=./kernel.bin of=./toy-os.img bs=512 count=200 seek=9 conv=notrunc

Where each binary sits on the disk, and who reads it into memory.

On a HiDPI screen, Bochs’s own X11 window is tiny and cannot be scaled. So make run starts Bochs with its VNC server (display_library: rfb) and opens it in Remmina, scaled up. Two catches: the Bochs VNC server only speaks 8-bit color, and it panics on the X11 keymap files, so it runs without one. The old window is still there as make run-x11. The screenshots in these posts come straight from that VNC framebuffer.

Power-on: the first instruction

A reset puts the CPU in real mode, the 16-bit mode of the 8086. Real-mode addresses are segment × 16 + offset, yet the first instruction does not come from CS × 16 + IP. Here is the Bochs debugger at instruction 0, before anything has run (trimmed):

Next at t=0
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b          ; ea5be000f0
rip: 00000000_0000fff0
cs:0xf000, dh=0xff0093ff, dl=0x0000ffff, valid=7
	Data segment, base=0xffff0000, limit=0x0000ffff, Read/Write, Accessed
CR0=0x60000010: pg CD NW ac wp ne ET ts em mp pe

CS holds 0xF000, but its base is 0xFFFF0000, not 0xF000 × 16 = 0xF0000. Every segment register has a hidden part, the descriptor cache, holding the base and limit the CPU actually uses. At reset the CPU loads a special value into it, so the first fetch is at 0xFFFF0000 + 0xFFF0 = 0xFFFFFFF0, 16 bytes below 4 GiB. The chipset maps the BIOS ROM there. That ROM has room for one instruction, a far jump: jmpf 0xf000:e05b reloads CS the normal real-mode way (base 0xF0000), and the BIOS carries on from its copy at 0xFE05B in the first MiB. (Post 2 is about this hidden part.)

CR0.PE = 0 (lower-case pe above) means real mode. The cache is also off (CD, NW) until the BIOS turns it on.

The BIOS loads sector 0 to 0x7C00

The BIOS runs its power-on self test (POST), sets up the interrupt vector table and its data area, finds the disks and prints a banner. Then it walks the boot order. For a hard disk, it reads LBA 0 (512 bytes) to 0000:7C00. If the last two bytes are 0x55 0xAA, it jumps there. I set a breakpoint at 0x7C00:

(0) Breakpoint 1, 0x0000000000007c00 in ?? ()
Next at t=7109628
(0) [0x000000007c00] 0000:7c00 (unk. ctxt): jmpf 0x0000:7c48          ; ea487c0000
rax: 00000000_0000aa55
rdx: 00000000_00000080
rsp: 00000000_0000ffd6

The BIOS ran 7.1 million instructions before the first byte of toy-os. DL = 0x80 is the boot drive (the first hard disk). AX = 0xAA55 is probably left over from the signature check.

The screen at that breakpoint. The BIOS has printed “Booting from Hard Disk…” and toy-os has not run yet.

Why 0x7C00? The usual explanation goes back to the IBM PC 5150. Its smallest model had 32 KiB of RAM, and its BIOS put the boot sector in the last 1 KiB of it: 0x8000 − 0x400 = 0x7C00, leaving 512 bytes above the sector for its data and stack.

Real-mode addressing and the first MiB

In real mode a segment register is just a number: the physical address is segment × 16 + offset. That gives 20 bits, 1 MiB. FFFF:FFFF would be 0x10FFEF, but the 8086 had only 20 address lines, so the address wrapped around to 0x0FFEF. Later CPUs keep that wrap-around until the A20 line is enabled (post 3).

This is the first MiB at the moment the MBR runs, with the two pieces toy-os has placed so far:

Physical memory below 1 MiB when the MBR runs (not to scale). “free” means unused RAM.

• 0x00000–0x004FF: the real-mode interrupt vector table (256 × 4-byte segment:offset pairs) and the BIOS Data Area. The BIOS needs both, and they must not be overwritten while the code still makes BIOS calls.
• 0x07C00–0x07DFF: the MBR. It sets sp = 0x7C00, so its stack grows down from just below itself.
• 0x00800–0x00FFF: where the MBR puts loader.bin, 4 sectors. It used to be at 0x900, as in the book, and moved to 0x800 in a later revision. The E820 memory map (post 6) sits just below it, at 0x500–0x784.
• 0x9F000–0x9FFFF: the Extended BIOS Data Area. From 0xA0000 up it is not RAM at all: video memory (the color text buffer is at 0xB8000), the VGA BIOS ROM at 0xC0000, and the system BIOS at the top.

The MBR

The MBR has 510 bytes of code and data, plus the signature. It does four things: it sets up the segment registers, clears the screen and prints, reads the loader, and jumps to it.

Segments and stack

%include "boot.inc"
SECTION MBR vstart=0x7c00
    jmp 0x0:mbr_entry
    ...
mbr_entry:
    xor ax,ax
    mov ds,ax
    mov es,ax
    mov ss,ax
    mov sp,0x7c00
    mov fs,ax
    mov ax,0xb800
    mov gs,ax

vstart=0x7c00 makes nasm assemble every label as an offset from 0, starting at 0x7C00. That only works if CS = 0. Most BIOSes jump to 0000:7C00, but some jump to 07C0:0000, which is the same physical byte with a different CS. The far jump at the top makes CS:IP = 0000:7C48 either way. (That is the jmpf 0x0000:7c48 in the debugger output above.) gs = 0xB800 points at the text buffer.

Printing through the BIOS

In real mode the BIOS does the work. int 10h with AH = 06h scrolls the window up, which clears the screen, and AH = 02h puts the cursor at the top left. The print routine lives in util.inc, shared by the MBR and the loader. It reads the cursor (AH = 03h), then writes the string (AH = 13h), which handles CR LF itself:

; cx should hold character count
; es:bp should point to the string
print_real_mode:
    ; get cursor position, dh = row, dl = col
    ; it also returns the cursor shape in cx, so save the count
    push cx
    mov ah,0x03
    mov bh,0x0
    int 10h
    pop cx
    ; Write string
    mov ah,0x13
    mov al,0x01
    mov bh,0x0
    mov bl,0x07
    int 10h
    ret

%include pastes the file where the directive is, so util.inc must go somewhere execution cannot fall into. It also refuses to assemble outside 16-bit code (%if __?BITS?__ != 16 / %error). Once the loader switches to 32-bit code, BIOS calls are gone for good.

Reading the loader with ATA PIO

There is no file system, just sectors. The MBR talks to the primary ATA controller through I/O ports, in 28-bit LBA mode:

After the command, the drive raises DRQ once per 512-byte sector, and each sector is 256 in ax, dx reads from the data port:

    ; the drive raises DRQ once per sector, wait before each one
.next_sector:
    ; reading 0x1f7 returns status
    ; status lags behind the command / last data word by up to 400ns
    ; 4 reads give the drive that time, so stale bits are not trusted
    mov dx,0x1f7
    in al,dx
    in al,dx
    in al,dx
    in al,dx
.not_ready:
    in al,dx
    ; bit 7 BSY = 1: the other bits are not valid yet
    test al,0x80
    jnz .not_ready
    ; bit 5 DF device fault, bit 0 ERR
    test al,0x21
    jnz disk_error
    ; bit 3 DRQ = 0: sector data not ready yet
    test al,0x08
    jz .not_ready

    ; data port, 256 words = one 512 byte sector
    mov dx,0x1f0
    mov cx,256
.go_on_read:
    in ax,dx
    mov [bx],ax
    add bx,2
    loop .go_on_read

    dec di
    jnz .next_sector
    ret

The first version (b5e42cb) did what the book does: it waited for DRQ once, then read count × 256 words in one go. That works in Bochs, but the protocol says to wait before each sector, and the status is only valid about 400 ns after the last access. In the revision (cbd7402) the MBR waits per sector, checks DF and ERR, and prints “Disk read error” and halts on failure. The MBR has no caller to return an error to, so halting is all it can do.

Then come the jump and the signature:

    mov eax,LOADER_START_SECTOR     ; LBA 2
    mov bx,LOADER_BASE_ADDR         ; 0x800
    mov cx,4
    call read_disk
    ...
    jmp LOADER_BASE_ADDR

times 510-($-$$) db 0
db 0x55,0xaa

Stopped at 0x800, the loader’s first instruction. Both lines were printed by the MBR through int 10h.

Two things have to stay in sync between the Makefile and the assembly (both are in my commit notes):

1. The seek=2 in the Makefile must match LOADER_START_SECTOR in boot.inc.
2. The dd count must match the number of sectors the MBR reads (mov cx, ...), and both must cover the whole loader.bin. At first the loader was smaller than one sector, so count=1 and mov cx, 1 were enough. Once it grew protected-mode code (post 3), it no longer fit, so both are now 4 (2 KiB; loader.bin is 881 bytes).

Next, the loader leaves real mode. First it needs a GDT, the subject of post 2.

References

1. 郑钢, 《操作系统真相还原》, ch. 2 (编写 MBR 主引导记录) and ch. 3 (完善 MBR): the MBR, the real-mode memory layout, and reading the disk through ports.
2. navi, 从零开始写 OS 内核 - BIOS 启动到实模式, segmentfault.
3. D. P. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd ed., Appendix A “System Startup”: the BIOS and the boot loader.
4. OSDev Wiki, ATA PIO Mode and Memory Map (x86).
5. Intel 64 and IA-32 Architectures Software Developer’s Manual, Vol. 3A, “Processor Management and Initialization”: the reset state and the first instruction executed.

Special Thank You

This blog is an almost identical replay of this educational video series:

• 【数学史】数学危机（上）——无穷小量的幽灵与分析学的严谨化

I personally find them extremely interesting, and wish I had watched them earlier when I was in college.

Before Introduction

Long before the debut of the second mathematical crisis, ancient Greek philosopher Zeno of Elea presented the famous “Zeno’s paradoxes”

In a race, the quickest runner can never over­take the slowest, since the pursuer must first reach the point whence the pursued started, so that the slower must always hold a lead.

To put numbers on the problem, say Achilles (the quickest runner) moves at 10 m/s and the tortoise (the slowest) moves at 1 m/s, and the tortoise was 9 m ahead of Achilles. Zeno is saying, the accumulated time that Achilles spent reaching the point the tortoise was, which can be calculated below

is going to extend forever and never ends.

Is $0.999\ldots$ ending somewhere?

That seemingly easy question has bothered the top minds of the entire globe for more than 150 years.

Introduction

The invention of calculus by Newton and Leibniz revolutionized mathematics. It just works!

Yet the foundations of calculus were surprisingly shaky. Mathematicians routinely manipulated infinitesimals—quantities smaller than any measurable number, yet somehow not zero. This worked extraordinarily well in practice, but philosophers questioned whether the arguments were logically sound.

This debate eventually led to the rigorous foundations of modern analysis during the nineteenth century.

1. George Berkeley (1685–1753)

“The Analyst; or, A Discourse Addressed to an Infidel Mathematician” (1734)

George Berkeley is better known as the philosopher of Idealism, summarized by the famous Latin phrase

Esse est percipi

(“To be is to be perceived.”)

Ironically, although remembered primarily as a philosopher and bishop, Berkeley understood contemporary mathematics remarkably well. His famous criticism was aimed not at the results of calculus, but at its logical foundations.

A famous quotation:

“And what are these Fluxions? The Velocities of evanescent Increments. And what are these same evanescent Increments? They are neither finite Quantities, nor Quantities infinitely small, nor yet nothing. May we not call them the ghosts of departed quantities?”

This “ghosts of departed quantities” became one of the most famous criticisms in the history of mathematics.

Example 1

Suppose

Take two nearby points

Then

At first,

• $\Delta x$ is treated as an ordinary nonzero number so division is allowed.

Later,

• we let $\Delta x=0$.

The simple question Berkeley asked was:

Is $\Delta x$ zero or is it not?

• If it is zero, division by it is impossible.
• If it is nonzero, why may we simply discard it?

He added that:

Qu. 63. Whether such Mathematicians as cry out against Mysteries, have ever examined their own Principles?

Qu. 64. Whether Mathematicians, who are so delicate in religious Points, are strictly scrupulous in their own Science? Whether they do not submit to Authority, take things upon Trust, and believe Points inconceivable? Whether they have not their Mysteries, and what is more, their Repugnancies and Contradictions?

2. Thomas Bayes (1701–1761)

Today Bayes is famous for Bayes’ theorem \(P(A|B) = \frac{P(B|A)P(A)}{P(B)}\) but during his lifetime he also wrote in defense of Newtonian calculus. He was also elected a Fellow of the Royal Society.

His two principal mathematical AND theological works include

• An Introduction to the Doctrine of Fluxions (1736)
• Divine Benevolence (1731)

Bayes argued that infinitesimals should be viewed as arbitrarily small quantities, not mysterious objects.

However, Berkeley’s criticism remained:

“Arbitrarily small” is still not zero.

Merely making something smaller does not explain why it may suddenly be treated as zero. The following example would be an even better illustration of the issue.

Example 2

If “Arbitrarily small” is still not zero, they are not equal. No room for ambiguity

We now know that these two terms are equal in the scope of real analysis. But one of the $\cancel{\text{misleading}}$ interesting proofs I myself was taught in middle school was:

Let \(S=0.9+0.09+0.009+\cdots.\)

Then \(10S=9+0.9+0.09+\cdots,\)

so \(9S=9,\)

thus \(S=1.\)

But from another perspective, this could also lead us to a ridiculous conclusion: \(S=9+90+900+\cdots.\)

Again,

leading to

so

The key piece here is that many operations valid for finite series do not work for infinite series.

3. Jean le Rond d’Alembert

Converging series:

There are non-converging series:

The first formal way to tell if an infinite series converges is the Ratio Test (d’Alembert’s test), named after Jean le Rond d’Alembert

If \(L=\lim_{n\to\infty}\left|\frac{a_{n+1}}{a_n}\right|,\)

then

• $L<1$: converges
• $L>1$: diverges
• $L=1$: inconclusive

Example for $L=1$, the Harmonic series:

Since

the Ratio Test cannot determine convergence for

At this time, there was still no formal definition of infinitesimals and limits.

Another fun fact about d’Alembert is, he worked with Denis Diderot in editing Encyclopédie. It was the first encyclopedia to include contributions from many named contributors and the first to describe the mechanical arts.

Instead of trying to define infinitesimals, d’Alembert proposed defining calculus using limits.

His article “Limite” in the Encyclopédie (edited by Diderot and d’Alembert, Le chevalier de Jaucourt, and numerous other contributors) famously states that infinitesimals are unnecessary and should be replaced by limiting processes.

A representative quotation:

“One does not pass to the limit; one approaches it as closely as one wishes.”

4. Euler and Lagrange

On the other side, there were people who did not care about the definition of infinitesimals at all.

Euler was unconcerned by philosophical objections.

“The objection that the analysis of the infinitely small neglects mathematical rigor disappears entirely, since nothing is rejected except what is absolutely nothing.”

Unlike Berkeley, Euler was primarily interested in solving mathematical and physical problems rather than debating philosophical foundations. His work spanned mechanics, astronomy, optics, fluid dynamics, number theory, and engineering.

To Euler, the remarkable success of infinitesimal methods in producing correct results was itself compelling evidence of their validity. This pragmatic attitude explains why he regarded Berkeley’s criticism as a philosophical concern rather than a mathematical obstacle.

By the way, Euler was a true virtuoso. He made groundbreaking contributions across mathematics, physics, astronomy, and engineering. Even after losing the sight in one eye and later becoming almost completely blind, he continued to produce an extraordinary volume of influential work, demonstrating remarkable perseverance alongside his unparalleled mathematical genius.

Joseph-Louis Lagrange attempted to eliminate infinitesimals entirely by rebuilding calculus upon Taylor’s theorem. He believed that differentiation should not rely on mysterious infinitesimal quantities, but instead on ordinary algebra and infinite polynomial expansions. In his Théorie des fonctions analytiques (1797), Lagrange argued that every sufficiently smooth function should be representable by its Taylor series, making infinite series—not infinitesimals—the true foundation of calculus.

Taylor Series

Brook Taylor was a younger contemporary of Isaac Newton and, like Newton, a Fellow of the Royal Society. In 1712, Taylor served on the Royal Society committee that examined the famous priority dispute between Isaac Newton and Gottfried Wilhelm Leibniz over the invention of calculus. Although Taylor is remembered today for Taylor’s theorem, his work was originally motivated by problems in finite differences and interpolation.

One of Newton’s many remarkable contributions was his generalization of the classical binomial theorem. Instead of restricting the exponent to positive integers, Newton showed that the expansion also works for fractional and negative exponents (later mathematicians extended it to arbitrary real and even complex exponents), provided the resulting infinite series converges.

\((1+x)^k = \sum_{n=0}^{\infty} \binom{k}{n}x^n = 1 + kx + \frac{k(k-1)}{2!}x^2 + \frac{k(k-1)(k-2)}{3!}x^3 + \cdots\) for any $k$ and $|x| < 1$, for convergence

At some point he was sure that all functions (not just binomial) should be able to expand as a polynomial series

Taylor’s key contribution was determining the coefficients of this infinite polynomial.

Suppose we wish to approximate a function around the point $x=x_0$.

For a zeroth-order approximation,

Including the first-order term gives

Including the second-order term,

The factor $\frac{1}{2!}$ appears because

so dividing by $2!$ ensures that the second derivative of the polynomial equals $f’‘(x_0)$.

Continuing this process, we arrive at Taylor’s theorem

Colin Maclaurin specialized Taylor’s theorem at $x = 0$:

Example 3

Let $x=2$

Adding more terms rapidly improves the approximation.

Example 4

Let $x=2$

Again, including more terms produces increasingly accurate approximations.

The problem of Taylor Series

Using Taylor Expansion, instead of using $\approx$ or putting a $=$ here with a guilty conscience, we can confidently place an $=$ between $0.99999\ldots$ and $1$, because

Therefore $f^{(n)}(0) = n!$

Substitute $x = 0.1$,

This method totally bypassed the definition of infinitesimals, but comes with a deadly imperfection. Taylor series do not always work well with some functions. If instead of $0.1$, but $x = 10$ was substituted in the above equation:

In another example:

Substitute with $x = 2$

However, if we substitute with $x = \frac{1}{2}$, it works again

These two failures only mean that the series diverges when $x$ is too far from $x_0$. The real blow to Lagrange’s program came from Cauchy in 1823: the function

is smooth everywhere and $f^{(n)}(0) = 0$ for every $n$, so its Taylor series at $0$ is identically $0$, yet $f(x) > 0$ for every $x \neq 0$. The series converges everywhere, just not to $f$.

So Lagrange’s hope that every sufficiently smooth function could be represented by its Taylor series died. What survives is Taylor’s theorem with a remainder term, which Lagrange himself gave in the same 1797 book: for some $\xi$ between $x_0$ and $x$,

5. Augustin-Louis Cauchy

If Berkeley exposed the logical weaknesses of infinitesimals, and Lagrange attempted to replace them with Taylor series, it was Augustin-Louis Cauchy who began rebuilding calculus on rigorous foundations.

Cauchy entered the École Polytechnique only a few years after Joseph-Louis Lagrange had taught there. His landmark textbook, Cours d’analyse (1821), marks the beginning of modern rigorous analysis.

“When the successive numerical values of the same variable decrease indefinitely, so as to fall below any given number, this variable becomes what is called an infinitely small quantity, or an infinitesimal.”

This is very close to the $\varepsilon-\delta$ language we see today.

Also, he was the first to prove Taylor’s theorem rigorously, establishing his well-known form of the remainder.

6. Karl Weierstrass

Karl Weierstrass has a famous function named after him, Weierstrass Function.

\(f(x) = \sum_{n = 0}^{\infty}a^n\cos(b^n \pi x)\) where $0<a<1$, $b$ is a positive odd integer, and $ab > 1 +\frac{3}{2}\pi$.

It is famous for being continuous everywhere but differentiable nowhere. People tend to think that continuous functions should be smooth after zooming in, but Weierstrass function proves them wrong.

And finally at this moment, as we take off from Leibniz defining continuity as “natura non facit saltus” or “nature makes no jump”, we finally arrive at the modern $\varepsilon-\delta$ definition of a limit, formalized by Weierstrass (building on Cauchy’s work), is as follows.

Let $f$ be a function defined on an open interval around $a$ (possibly excluding $a$ itself). We say

if and only if

References

1. Berkeley, G. (1734). The Analyst; or, A Discourse Addressed to an Infidel Mathematician.
2. Bayes, T. (1736). An Introduction to the Doctrine of Fluxions.
3. Bayes, T. (1731). Divine Benevolence; or, an Attempt to Prove that the Principal End of the Divine Providence and Government is the Happiness of His Creatures.
4. d’Alembert, J. le Rond. (1751–1772). “Limite,” in Encyclopédie, edited by Denis Diderot and Jean le Rond d’Alembert.
5. Euler, L. (1755). Institutiones Calculi Differentialis.
6. Lagrange, J.-L. (1797). Théorie des fonctions analytiques.
7. Cauchy, A.-L. (1821). Cours d’analyse de l’École Royale Polytechnique.
8. Weierstrass, K. (1872). “Über continuierliche Funktionen eines reellen Arguments, die für keinen Werth des letzteren einen bestimmten Differentialquotienten besitzen.”
9. Grabiner, J. V. (1981). The Origins of Cauchy’s Rigorous Calculus.
10. Boyer, C. B., & Merzbach, U. C. (2011). A History of Mathematics (3rd ed.).
11. Kline, M. (1972). Mathematical Thought from Ancient to Modern Times.
12. Stillwell, J. (2010). Mathematics and Its History (3rd ed.).

Following the previous blog, this is somewhat of a separate thread, which records my attempt to optimize the SGEMM kernel to the extreme.

I know there are many excellent engineers who have already achieved this, but to be honest, their code is often very hard to understand.

I will update this blog occasionally, as GPU is really not the focus of my work, but it still fascinates me a lot.

Again, source code can be found here.

Table of Contents

• Test Environment Setup
• Part 8: Warp Tile (v5)
  • Nsight Analysis of the previous kernel sgemm_v4
  • Better memory access management with warp tile
  • LDS.128 Shared Memory Transactions
• Part 9: Coalesced Writeback using Cs (v6)

Test Environment Setup

After finishing grad school, I have to switch my test platform from the high end AD102GL [RTX 6000 Ada Generation] workstation to the cheapest Google VM I can get with Nvidia L4 GPU

Google has a really nice script that automates the installation of GPU drivers and CUDA tools.

curl -L https://storage.googleapis.com/compute-gpu-installation-us/installer/latest/cuda_installer.pyz --output cuda_installer.pyz
sudo python3 cuda_installer.pyz install_driver
reboot
sudo python3 cuda_installer.pyz install_cuda
reboot

Part 8: Warp Tile (v5)

Nsight Analysis of the previous kernel sgemm_v4

Using Nsight Compute, we can profile and analyze memory behavior.

sudo $(which ncu) --set full -o profile_output -f ./sgemm_v4 4096 4096 4096
ncu -i profile_output.ncu-rep > sgemm_v4.txt

Below is part of the profile result of sgemm_v4.

    Section: Memory Workload Analysis Tables
    OPT   Est. Speedup: 58.32%                                                                                          
          The memory access pattern for global stores to L1TEX might not be optimal. On average, only 4.0 of the 32     
          bytes transmitted per sector are utilized by each thread. This could possibly be caused by a stride between   
          threads. Check the Source Counters section for uncoalesced global stores.                                     
    ----- --------------------------------------------------------------------------------------------------------------
    OPT   Est. Speedup: 27.27%                                                                                          
          The memory access pattern for shared loads might not be optimal and causes on average a 5.0 - way bank        
          conflict across all 134217728 shared load requests.This results in 268435456 bank conflicts,  which           
          represent 40.00% of the overall 671091703 wavefronts for shared loads. Check the Source Counters section for  
          uncoalesced shared loads.                                                                                     
    ----- --------------------------------------------------------------------------------------------------------------
    OPT   Est. Speedup: 22.72%                                                                                          
          The memory access pattern for shared stores might not be optimal and causes on average a 2.4 - way bank       
          conflict across all 20971520 shared store requests.This results in 16777216 bank conflicts,  which represent  
          33.33% of the overall 50331648 wavefronts for shared stores. Check the Source Counters section for            
          uncoalesced shared stores.              

There are two major problems:

• Memory access to global memory is not coalesced, wasting bandwidth. Therefore, threads within a warp should write to contiguous global memory addresses.
• Shared memory load/store conflicts => mostly when loading and storing back to global memory

Better memory access management with warp tile

Credit: The following illustrations comes mostly from Advanced Matrix Multiplication Optimization on NVIDIA GPUs, the same hierarchy was mentioned in this paper Strassen’s Algorithm Reloaded on GPUs.

In sgemm_v4, each thread reads off a $1 \times 4$ floats (float4) from global memory and then stores a $4 \times 1$ to AsT shared memory:

float4 a4 = FLOAT4(A[OFFSET(a_row, a_col, M, K)]);
AsT[shmem_col][shmem_row] = a4.x;
AsT[shmem_col + 1][shmem_row] = a4.y;
AsT[shmem_col + 2][shmem_row] = a4.z;
AsT[shmem_col + 3][shmem_row] = a4.w;

However in sgemm_v5, each thread reads off a $4 \times 1$ but stores $1 \times 4$ floats (float4) to shared memory:

auto ld_g2r_a = [&] (int ph) {
      int col = ph * 8 + A_thread_col;
      A_ldg_reg.x = (A_row < M && col < K) ? A[OFFSET(A_row, col, K)] : 0.0f;
      A_ldg_reg.y = (A_row + 1 < M && col < K) ? A[OFFSET(A_row + 1, col, K)] : 0.0f;
      A_ldg_reg.z = (A_row + 2 < M && col < K) ? A[OFFSET(A_row + 2, col, K)] : 0.0f;
      A_ldg_reg.w = (A_row + 3 < M && col < K) ? A[OFFSET(A_row + 3, col, K)] : 0.0f;
};

auto st_r2s_a = [&] () {
      FLOAT4(AsT[A_thread_col][A_thread_row]) = A_ldg_reg;
};

I think both approaches need 128 memory transactions (32-byte sectors) to load $128 \times 8$ floats from the global memory, because each row of the tile is only 8 floats (32 bytes) wide, a quarter of a 128-byte cache line.

However, when it comes to storing into the shared memory, sgemm_v5 uses vectorized store to better utilize the shared memory bandwidth, while sgemm_v4 does not.

Bank conflict-wise (at this stage, before computation), both schemes are clean. Specifically, sgemm_v5 intentionally inserts 4 columns to “shift” away the conflicts.

sgemm_v5 also has a very clever memory access arrangement for B. For the most part, all memory load from global memory are obviously coalesced. When storing to shared memory, there are also no bank conflicts.

LDS.128 Shared Memory Transactions

Credit: The following section relies heavily on this Zhihu Blog 搞懂 CUDA Shared Memory 上的 bank conflicts 和向量化指令（LDS.128 / float4）的访存特点 and YHs_Sample sgemm.

The big picture of warp tile looks like this:

But unlike what one would expect, how threads within a warp are mapped to shared memory is not simple and trivial. sgemm_v5 uses the following mapping.

This is because of the presence of a broadcast limitation if we simply put neighboring threads next to each other.

LDS.32, LDS.64 and LDS.128 are the SASS (machine code) instructions used when threads load 32 bits (one float), 64 bits and 128 bits (four floats or float4) from shared memory. Their PTX counterparts are ld.shared.f32, ld.shared.v2.f32 and ld.shared.v4.f32.

LDS.32

• When multiple threads access the same word (32-bit) (thus of course within the same bank), the broadcast mechanism is triggered. That word is simultaneously sent to the corresponding threads.

If all threads within a warp reads the same word, only 1 memory transaction

• When multiple threads access different words within the same bank, a bank conflict occurs. The request is then split into multiple memory transactions, which are issued serially for execution.

If all threads within a warp reads totally different words in the same bank, 32 memory transactions needed.

LDS.64

Each thread requesting 2 words, thus 16 threads together saturate the 128-byte transaction size. The hardware then splits one warp (32 threads) into 2 half-warps (16 threads), leading to two memory transactions.

Only under certain scenarios will these two memory transactions be merged into one. For all active threads in a warp (where active means the thread has a memory access request):

• For thread i, thread i xor 1 is either inactive or accesses the same memory address.

(i.e., T0 == T1, T2 == T3, T4 == T5, T6 == T7, etc.)

• For thread i, thread i xor 2 is either inactive or accesses the same memory address.

(i.e., T0 == T2, T1 == T3, T4 == T6, T5 == T7, etc.)

Example 1: 32 threads accessing 32 consecutive uint2

• Does not meet the above requirements
• First half-warp will access the first 128 bytes, causing one memory transaction
• Second half-warp will trigger another

Example 2:

• T0 == T1, T2 == T3, …
• One merged memory transaction

LDS.128

Each thread requesting 4 words, thus 8 threads alone will saturate the 128 bytes of data. The hardware then splits one warp (32 threads) into 2 half-warps (16 threads), and each half-warp into 2 quarter-warps (8 threads), leading to up to 4 memory transactions.

Only when the same rule applies (as the above mentioned LDS.64) will the group of quarter-warp memory transactions be merged into one “half-warp” memory transactions, however these “half-warp” memory transactions will not further be merged into 1, meaning there will at least be 2 memory transactions.

Example 1: 32 threads accessing 32 consecutive uint4

• Does not meet the requirements
• Total of 4 quarter-warp memory transactions

Example 2: Thread 15 and Thread 16 access the same uint4

• Does not meet either requirement
• 2 quarter-warp memory transactions

Example 3: Thread 0 and Thread 15 access the same uint4

• Meet both requirements
• 1 merged half-warp memory transaction

Example 4: Irregular scenario

• First half-warp meets the first requirement; Second meets the second
• The requirement needs to be coherent across the entire warp, therefore the warp meets neither the first requirement nor the second
• 4 memory quarter-warp transactions

How it associates with SGEMM kernel here

When threads are reading segments from shared memory, they are progressively reading float4s, and that is the “32 threads accessing 32 consecutive uint4” mentioned in the above section

From the previous sections, we get to see that we should either put

• (t0, t1), (t2, t3), … reading the same word
• (t0, t2), (t1, t3), … reading the same word

And that is exactly what we observed from sgemm_v5:

• When reading col frag from As (row frag from AsT), T0 = T2, T1 = T3, …
• When reading row frag from Bs, T0 = T1, T2 = T3, …

This Z shaped mapping will make quarter-warp memory transactions merged into half-warp transactions

Part 9: Coalesced Writeback using Cs (v6)

In sgemm_v5, I “shuffled” threads within the warp in a zig-zag fashion, as mentioned above, to reduce the LDS.128 memory transactions.

sgemm_v5 directly stores those results from per-thread registers to global memory, and since we adopt the zig-zag layout, they are no longer coalesced. Optionally, we can use shared memory as an intermediate buffer to rectify global memory access pattern.

__shared__ __align__(16) float Cs[8][16][36];
auto st_r2g_c = [&] () {
      #pragma unroll
      for (int i = 0; i < 2; i++) {
            #pragma unroll
            for (int j = 0; j < 2; j++) {
                  #pragma unroll
                  for (int row = 0; row < 4; row++) {
                        FLOAT4(Cs[warpId][frag_row * 4 + row][frag_col * 4]) = FLOAT4(acc[4 * i + row][4 * j]);
                  }
                  __syncwarp();

                  const int c_col = block_col + warp_col + j * 32 + laneId;
                  
                  #pragma unroll
                  for (int p = 0; p < 16; p++) {
                        const int c_row = block_row + warp_row + i * 16 + p;
                        if (c_row < M && c_col < N) {
                              C[OFFSET(c_row, c_col, N)] = Cs[warpId][p][laneId];
                        }
                  }
                  
                  __syncwarp();
            }
      }
};

Each warp writes into its [16][36] intermediate buffer, and then we flush the 16 rows one by one. Note that __syncwarp() instead of __syncthreads() is used, because each warp independently works on its own Cs[warpId] array, we only need threads within a warp to synchronize.

There is an obvious tradeoff to make here, as in sgemm_v6 we have more synchronizations but our store to the global memory is coalesced.

On the Nvidia L4 GPU I am using, this actually hurts the performance a little bit.

Future Works

1. Have more illustrations
2. Consider bank conflict of registers
3. Double buffering
4. PTX analysis and so on

References

• Strassen’s Algorithm Reloaded on GPUs
• Advanced Matrix Multiplication Optimization on NVIDIA GPUs
• Inline PTX Assembly in CUDA
• 搞懂 CUDA Shared Memory 上的 bank conflicts 和向量化指令（LDS.128 / float4）的访存特点
• YHs_Sample sgemm