kmem: a slab allocator, and what the fixed tables actually cost

Gate 0's last structural row. kernel/core/kmem.c: slabs are pages from
kalloc() with a header at the front, and free objects hold the free list in
their own first eight bytes.

That last detail is the whole design. **An object carries no header and
freeing performs no search**: the page base of any object *is* its slab, and
the slab names its cache. It is also exactly why an object cannot exceed a
page, which matters below.

Two interfaces. kmem_cache_create/alloc/free for a subsystem with one kind of
thing -- it gets its own line in /proc/slab, which is most of why naming it is
worth the argument -- and kmalloc/kmfree over power-of-two classes from 16 to
2048 for code with no single type to build a cache around. Each cache keeps
partial and full lists; a slab that empties goes straight back to kalloc()
rather than being kept, so /proc/slab never overstates what is held.

`make kmem-test` asserts the bookkeeping on the build machine. Same arrangement
as schfs-objtest, and for the same reason: slab lists, free-list threading, the
page-to-cache lookup and whether pages actually come back are all things that
can be wrong without a kernel to be wrong in. 26 checks, including one that a
permissive allocator cannot pass -- write a distinct pattern through 512
objects and read them all back, because two objects sharing storage shows up
there and nowhere else.

One bug the test found immediately: kmem_max_obj() returned the raw page
remainder, which kmem_cache_create() then rounded *up* past its own limit. The
largest legal size was reported as illegal.

**It does not do what the register said it would.** The claim was that every
fixed table exists to work around kalloc. Measured:

    struct proc    10656    NPROC 128     larger than a page
    struct socket   4928    NSOCK 32      larger than a page
    struct buf      4272    NBUF 256      larger than a page
    struct inode     280    NINODE 200    a cache, bounded on purpose
    struct device    120    NDEVICE 32    3.8 KB, never hit
    struct file       48    NFILE 512     24 KB, never hit

The three largest cannot go in a page-backed slab whatever it does. NINODE is
a cache and is meant to be bounded. NFILE and NDEVICE are small enough that
their tables are rounding errors and their ceilings have never been reached.
Freeing the big ones needs a contiguous multi-page allocator, which is a
different thing and is not written. That is now in the register and in
docs/architecture/kernel.md rather than left as a claim nobody checked.

What it does fix is real, and was measured rather than assumed:

  - **A pipe is 640 bytes and came from a whole 4096-byte page.** Every `|` in
    a shell command burned three and a half kilobytes it never touched. Six
    pipes per page now, and /proc/slab shows the page going back when they
    close.
  - **procread() built its answer in a 2048-byte array on the kernel stack**,
    under a comment that had warned about exactly that since it was written --
    it stayed a local because a whole page for 2 KB felt worse, and kmalloc is
    the answer that was missing. Its frame is 64 bytes now instead of ~2100.
  - procfs's other generator took a page from kalloc for the same 2 KB.

Verified on a boot: /proc/slab tracks pipe and kmalloc-2048 through real
pipelines, allocs and frees balance, and $(), ps, time, readlink, sigtest and
rename are all still green with no traps.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/architecture/kernel.md

@@ -111,6 +111,54 @@ one per-CPU block and everything that changes per CPU belongs in it.
 > machine with more than one core. `include/proc.h` carries the disassembly that
 > proves it.
 
+## Memory
+
+`kalloc()` hands out one 4096-byte page and `kfree()` takes it back. That is the
+whole page allocator: a free list threaded through the free pages themselves,
+no buddy system, no zones, no page-frame database.
+
+### Small objects
+
+`kernel/core/kmem.c`, `include/kmem.h`. A slab is one page from `kalloc()` with
+a header at the front and objects packed after it; free objects hold the free
+list in their own first eight bytes.
+
+That last detail is the whole design. **An object needs no header and freeing
+needs no search**: the page base of any object *is* its slab, and the slab
+names its cache. It is also why an object cannot exceed a page.
+
+| | |
+|---|---|
+| `kmem_cache_create/alloc/free` | a named cache of one object size, for a subsystem with one kind of thing |
+| `kmalloc` / `kmfree` | power-of-two classes from 16 to 2048, for code with no single type to build a cache around |
+
+Each cache keeps `partial` and `full` lists; a slab that empties completely
+goes straight back to `kalloc()` rather than being kept, so `/proc/slab` never
+overstates what the kernel is holding.
+
+`make kmem-test` asserts the bookkeeping on the build machine — the same
+arrangement as `schfs-objtest`, and for the same reason: slab lists, free-list
+threading and whether pages actually come back are all things that can be wrong
+without a kernel to be wrong in.
+
+### What the fixed tables actually cost
+
+The standing claim was that every fixed-size table in the kernel exists to
+avoid asking `kalloc` for something smaller than a page. Measured, that is only
+partly true:
+
+| | size | table | |
+|---|---|---|---|
+| `struct proc` | 10656 | `NPROC` 128 | larger than a page |
+| `struct socket` | 4928 | `NSOCK` 32 | larger than a page |
+| `struct buf` | 4272 | `NBUF` 256 | larger than a page |
+| `struct inode` | 280 | `NINODE` 200 | a cache, bounded on purpose |
+| `struct device` | 120 | `NDEVICE` 32 | 3.8 KB, never hit |
+| `struct file` | 48 | `NFILE` 512 | 24 KB, never hit |
+
+The three largest cannot go in a page-backed slab at all. Freeing them needs a
+contiguous multi-page allocator, which is a separate thing and is not written.
+
 ## Processes
 
 `struct proc` in [`include/proc.h`](../../include/proc.h). A fixed table of