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/plan/1.0.md

@@ -269,11 +269,34 @@ These are the galling ones — the replacement exists, is tested, and is unused.
 
 **Structural, because everything after this compounds on it:**
 
-- [ ] **A slab or pool allocator.** `kalloc` hands out one page at a time, and
-      every subsystem written since has invented its own fixed-size table to
-      work around it — `NPROC`, `NSOCK`, `NDEVICE`, `NSHM`, `MAXJOBS`. This is
-      the single change that most improves everything else in the kernel, and
-      it gets more expensive with every table added.
+- [x] ~~**A slab or pool allocator.**~~ `kernel/core/kmem.c`. Slabs are pages
+      from `kalloc()` with a header at the front; free objects hold the free
+      list in their own first eight bytes, so an object needs no header and
+      freeing needs no search — the object's page base *is* its slab, and the
+      slab names its cache. Two interfaces: named `kmem_cache` for a subsystem
+      with one kind of thing, and `kmalloc`/`kmfree` over power-of-two classes
+      for everything else. Visible in `/proc/slab`, asserted by
+      `make kmem-test` on the host — the same arrangement as `schfs-objtest`,
+      so the bookkeeping is checked in a second rather than in a boot.
+
+      **It does not do what this row said it would, and that is worth
+      recording.** The claim was that every fixed table — `NPROC`, `NSOCK`,
+      `NDEVICE`, `NFILE`, `NINODE`, `NBUF` — exists to work around `kalloc`.
+      Measured: `struct proc` is 10656 bytes, `struct socket` 4928, `struct
+      buf` 4272. **All three are larger than a page**, so a page-backed slab
+      cannot hold them whatever it does; `NINODE` is a cache and is supposed to
+      be bounded; and `NFILE`/`NDEVICE` are 48 and 120 bytes, where the table
+      costs 24 KB and 3.8 KB and the ceiling has never been reached. The tables
+      were not all working around `kalloc`. Freeing the big ones needs a
+      contiguous multi-page allocator, which is a different thing and is not
+      written.
+
+      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, so every `|` in a shell
+      command burned 3.5 KB it never touched — **six pipes per page now**. And
+      `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;
+      its frame is 64 bytes now instead of ~2100.
 - [x] ~~**SchFS on-disk format version policy.**~~ Done. `SCHFS_VERSION` for
       frame changes, plus `compat`/`ro_compat`/`incompat` feature flags in what
       was `reserved0` — so existing images keep every field offset and read