Kernel overhaul: smaller fixed-platform services and their performance gates

A kernel overhaul can address memory and work that isolated hot-function changes leave intact. The evidence supports focused subsystem replacements, not an unbounded rewrite or a promise that every service can become tiny. The objective remains ordinary 64 compatibility with at least the retained reference's usable title capacity and no noticeable performance tradeoff.

What has already been inspected and changed

The investigation includes the reconstructed memory manager, page ownership, pool geometry/lifetimes, cache/write-back, retained storage callbacks, worker ownership, linked code families, public ABI, and selected real-title host/guest paths. The wiki now has a complete owned emitted-extent ledger and complete physical ownership for its measured allocation checkpoint.

Implemented work has primarily removed unnecessary boot/runtime lifetimes and repeated operations: decompression scratch, obsolete boot structures, dense pin-batch scratch, duplicate allocation metadata, eager bounce backing, terminated stacks and cache/allocator churn. Selected lower-level throughput and pin/alias paths were tested. INIT placement, LTO, section collection and export rooting already exist.

We have not yet replaced the general retained storage/device framework with a minimal fixed-Xbox service, nor produced a comprehensive per-subsystem frame-critical profile across every game. A function inventory is not an exhaustive runtime profile; an export wrapper is not the complete implementation cost. The missing architectural work should be stated directly rather than described as already finished.

Evidence for structural work

The exact plain-main .text compiler-extent union is 316,892 bytes, with 12,040 additional .text bytes outside that attribution. The largest attributable families include:

Owned family	.text extent-union bytes	Why it matters
Xbox-specific kernel/runtime	47,014	Memory, loader, cache and compatibility implementation; inspect per-service ownership
VFAT filesystem	44,444	FATX operations plus retained generic dispatch/query and supporting paths
Dispatcher/kernel core	34,777	Scheduling, waits, interrupts and lifecycle; correctness-critical shared roots
I/O manager	32,547	Dispatch, naming, IRPs, completion and cancellation used by multiple services
IDE storage	31,568	PnP/channel/request runtime and callbacks
Object manager	21,563	Handles, namespaces, references and lifetime
Storage class	15,359	Generic class requests, sense/error handling and completions
Executive	12,784	Queues, workers, allocation and initialization support
HAL	11,200	Hardware contracts, interrupt/timer/device support
XDVDFS	6,895	Disc filesystem contracts
Partition manager	4,590	Device/partition layer and management

These labels are disjoint attribution using historical owned source matches. There are also unresolved/ambiguous extents and other families; this abbreviated table is not the entire union. No listed family is wholly removable. The full reconciled table and root sizes are in Memory-Reduction-Targets.

Storage and filesystem families VFAT+IDE+class+XDVDFS+partition total 102,856 bytes. I/O adds shared work, not an exclusively removable storage subtotal. A 10,516-byte filesystem dispatch body or 5,081-byte PnP dispatch body is a lead for specialization; exact page recovery still depends on its exclusive closure and neighbors.

Workstream A: boot discovery versus resident storage

The fixed Xbox topology does not necessarily need all general enumeration/construction logic after the runtime stacks exist. The first bounded target is #142: trace the actual retained PnP route, specialize or retire the proven boot-only arm, and count its rebuilt exclusive closure.

Lifetime	Candidate responsibility	Required resident behavior
Initial boot	Discover fixed devices, assign resources, construct stacks and callbacks	Publish valid final runtime objects before releasing boot state
Runtime ordinary I/O	Reads/writes and request completion	Exact bytes, statuses, ordering, cancellation and synchronization
Runtime exceptional I/O	Media changes, retries, short transfers and device errors	Preserve recovery; do not convert HDD metadata errors to false disc failures
Reset/shutdown	Drain requests, preserve required memory and reconstruct devices	No callback into discarded code, no persisted buffer destruction

Before retiring code, audit public/private dispatch copies, channel interfaces, timers/DPCs, queued workers, completion pointers and returning frames. A boot seal on one public table does not revoke all consumers. Prefer one independently measurable layer at a time; do not replace ATA, class, partition and filesystem semantics in one PR.

A successful first slice must show actual resident pages returned, not merely a renamed dispatch function. Only then consider whether the general layer itself can be replaced by a smaller fixed-platform runtime preserving the existing public I/O interface.

First implemented slice: PCIIDE boot dispatch lifetime

Ready PR #152 implements the narrow callback-family change. The public entry remains resident and rejects post-seal requests, including calls through a saved entry pointer. An admission gate tracks active calls, closes before retirement, and drains the private boot body before INIT donation. A bounded failed drain stops boot instead of donating pages with a live return address. Completion, channel-interface, interrupt and DPC callbacks stay resident; this does not remove runtime storage error recovery.

The unchanged public allocation/lifetime guest completed on ordinary 64 MiB xemu. The owned physical census resolves every unavailable page and confirms 332 → 330 unavailable pages, with resident kernel image backing 102 → 100 pages (408 → 400 KiB). Only resident .text loses two pages; pool backing (86 pages), public stacks (37 pages), and every other physical owner remain unchanged. This is 8 KiB of actual recovered RAM, not merely compressed ROM bytes or an inferred emitted-function size.

The latest reconstructed source is 547c79872006229965ab5e5e414f99a04481f727; the rebuilt release64 flash matches the observed candidate byte-for-byte. Production-body lifecycle tests and the 113-test host suite pass (three skips). Independent review checked the surviving published callbacks. Native64/128 storage byte checks, snapshot save/restore, media removal/reinsertion, QMP reset and guest warm reboot now pass on both main and candidate. Each storage run passes81 first-boot and82 post-reset checks; each guest warm-reboot run passes7/7 checks with normal exit. Broader error/retry behavior, actual target unexpected post-seal entry and title performance remain qualification gates. The PR is Ready and unmerged; neither a completed whole-kernel redesign nor an FPS gain is claimed.

Workstream B: allocator state and actual page populations

Pool backing reuse is the immediate bounded candidate. A broader allocator redesign should optimize real mixed lifetimes and physical packing, not nominal request capacities. Existing broad finer-class experiments modeled 117–125 pages instead of 86 and were not an improvement.

Private structure changes should be ranked by whether they cross a useful objects-per-page threshold. Large objects may need safe remainder reuse to save a physical page. Metadata redesign must preserve interior query/free, alignment, ordinary/reserved domains, rollback and failure behavior. Measure warm paths, refills and pressured fallback separately.

The PFN links+pin state+pool metadata own 27 pages /108 KiB in main. Dense scratch is already gone. Compact state remains a valid architectural vector, but the tested five-byte encoding worsened pin/unpin cost approximately 23–48%; it is not acceptable on byte count alone. Do not create dynamic metadata allocation under the PFN lock to avoid a static table.

Workstream C: fewer resident execution contexts

The measured public stack difference motivates worker-lifetime work, not a global stack-minimum reduction. #143 should first determine whether one retained execution context can safely disappear.

Inspect actual queue producers/consumers, blocking relationships, direct reaper submissions, APC/DPC/IRQL constraints and reset/shutdown. The single guest CPU does not make independent blocking contexts unnecessary. Dynamic escalation and the balance manager already disabled on Xbox are not new savings.

One eliminated 12 KiB stack, associated thread/object state and any now-exclusive support code should be charged in their actual physical owners. Do not count the idle stack again outside image/BSS.

Workstream D: filesystem service specialization

#141 begins with the retained dispatch/query closure. Keep FATX create/open, fragmented chains, allocation versus EOF, overwrite/reextend, directory growth, rename, truncate, save/reopen and error propagation explicit.

Previous save and false-disc failures show why shrinking a filesystem by removing unusual paths is risky. Only an owned-source consumer/lifetime proof can establish an unused arm. An independently authored public operation fixture must cover the changed contract, including short/permanent I/O failure. General FAT 12 handling already pruned cannot be presented as new recovery.

Removing an unnecessary mapping/request can lower downstream emulator work as well as guest instructions. Measure calls avoided, mapping changes, bytes copied and actual I/O; then use release title validation for the affected path. A faster API body alone does not establish faster loading or frames.

Workstream E: readonly placement and ROM-backed cold code

ROM execution can recover backing without deleting the service, and a container up to 1 MiB is allowed. Memory-ROM-and-Cold-Code and Memory-Comparison-and-Removal-Guide preserve the current implementation and known failures.

Not everything can execute or live directly in ROM: mutable state, self-modified bodies, patched data, fault/reset consumers and relocation-dependent structures need explicit handling. A split retaining hot pages in RAM and placing proven cold closures in ROM is a separate measured candidate; shared-page placement and access patterns decide real savings.

The narrow warm TCG test does not simulate physical flash latency, larger working sets or instruction-boundary costs. The historical PGR 2 bugcheck remains a separate gate. No evidence establishes that broad direct-ROM execution explains Complex's small resident kernel.

Performance investigation for an overhaul

For each subsystem, record the whole lifetime and work it causes:

1. Guest operation and caller: steady state, boot, level load, save or reset.
2. Guest execution versus waiting: call frequency, CPU work and blocking intervals.
3. Downstream emulator work: mappings/TLB invalidations, dirty tracking, device requests and synchronization.
4. Memory cost: image pages, object backing, metadata, stack and temporary peak.
5. Useful progress: correct completion, bytes/requests processed, guest flips and frame-time tails.

Avoid summing parallel CPU/GPU/APU times into a frame budget. A pool path occupying 0.011499% of one observed Conker menu window is not an FPS target for that scene; it can still be a memory-lifetime target or important during another phase.

Compile/runtime-gated discovery instrumentation may establish the mechanism. Ordinary release binaries determine performance claims. Do not instrument every tiny function synchronously, log per call in hot paths, or add permanent allocation-heavy profiling to the release kernel.

PR delivery and acceptance

Slice	Product change	Focused proof before broad testing
Pool reuse	Finish existing#135	Live-content replay, domains and public allocation contract; release title tails
PnP lifetime	One proven boot-only retained route	All surviving callback roots, reset/errors and rebuilt page difference
Worker ownership	At most one unnecessary context	No self-wait/deadlock, queue completion and measured stack depth
Filesystem closure	One dispatch/query responsibility	Full affected public contract, persistent save/reopen and short/failure I/O
PFN representation	One separately attributed compact-state design	Alias/overflow/rollback and operation cost before native campaigns
ROM/hot-cold split	One placement cluster	Mutable/fault/reset exclusions, access cost and title compatibility

Qualification should scale with the changed contract. Do not require another universe-sized campaign for a harmless placement annotation, but do not infer runtime safety from CI when callbacks or blocking ownership change. Keep source changes, reusable fixtures and private discovery evidence distinct. Evidence does not enter product main.

Completion means fewer uniquely owned physical pages, preserved title allocation capacity and functionality, and no meaningful lost useful progress or significant frame-time-tail increase. Saving source lines, compressed bytes or sampled CPU in an inactive path is not completion.

Decision

Yes: investigate a lower-level kernel overhaul. Start with a fixed-platform boot/runtime storage split and worker ownership, while completing the already measured pool saving. The entire kernel does not need replacement at once. Actual game minimum-free capacity and contiguous pressure should determine how urgently the remaining approximately 1% installed-RAM gap must be addressed, and which physical owner matters most.

October 10: native discovery and the next structural boundary

Two bounded Steam Deck user-cycle recordings completed with normal emulator exits. The existing sampler used cycles:u at97Hz with the monotonic clock and an external xemu perf map; both recordings parse successfully with zero recorded lost events. Symbol attribution uses the matching unstripped SpiritBoot image. These are discovery recordings, not uninstrumented performance comparisons.

Authored observation window	Direct kernel JIT sampled-period share	Largest observed host-side work	Interpretation
Conker menu, PR152 BIOS	0.830%	Three disjoint TB lookup/helper/hash leaves total14.290%; libsamplerate6.248%	Both boundary images show the normal animated bar menu. Forty kernel samples are sparse evidence, not a comprehensive per-function cost census.
PGR2, plain-main BIOS	0.888%	libsamplerate26.312%; physical32-bit load5.335%; translation-internal2.695%	The unchanged input route's window begins during the course flyover and ends at the parked red-car start. It is a mixed transition recording, not a stationary performance result.

Host-library percentages include unresolved internal symbols. Host helpers are not charged back to guest callers. Sampling does not measure blocking, GPU execution, inclusive BIOS-caused host work or frame-critical elapsed time. The percentages cannot establish an upper bound on architectural gains. The emulator is the pinned clean reference dcc536830deba245eec36cd009db5860ca04884c, not a claim about every subsequent fork change. Existing xemu#329 already investigates the lookup path; this recording does not create another duplicate optimization.

The largest directly attributed kernel entries are timer/interrupt/dispatch functions. No new dominant cache-hit or pool function is established in the Conker menu. The actionable BIOS question remains which mappings, object lifetimes and I/O requests can be avoided, alongside structural resident-size reduction.

Fixed-FATX specialization: a measured counterfactual

Issue156 tracks a fresh plain-main release64 experiment. Making the Xbox format predicate constant removes1,440 .text bytes and crosses one page boundary: linked resident image408→404KiB. This is not an actual physical-owner census, a title-capacity result or a speedup. The experimental edit was restored; no firmware containing it was deployed or merged.

The mount path recognizes FATX16/FATX32, but the public filesystem control device and mounted volumes have different extension layouts. Tracing further shows that NtQueryVolumeInformationFile rejects ordinary direct-device queries other than FileFsDeviceInformation, which it answers itself before filesystem dispatch. That substantially narrows the initially suspected public control-device query route; it does not prove every internal/custom IRP consumer or all teardown paths. There is no reproduced boundary fault to claim or fix yet.

The next implementation gate is a caller/lifetime proof and focused public-operation regression, followed by a safely scoped specialization. If the safe form loses the page saving, retain that result rather than removing a guard merely to meet a size number.

Qualification status

PR152's eight Windows PGR2 ABBA/BAAB runs completed with all boundaries visually checked: guest cadence+0.03%, process CPU+0.22%, p95+0.01%, p99−3.81%. The eight Windows Conker runs have also completed with normal exits and16 reviewed menu images: guest cadence+0.018%, process CPU−0.028%, p95+0.239%, p99−0.256%. Both show essentially unchanged capped cadence, not an FPS gain. The Deck's original corrupted-texture run remains excluded under issue154; subsequent normal retained-state diagnostics do not erase it or identify its cause. PR152 remains unmerged.

Actual title memory headroom at retained checkpoints

Read-only analysis of the existing paused physical RAM captures resolves virtual globals through each captured CR3 and the matching exact image. The allocator's free-page flags agree with its public available-page counter. The kernel-preferred and title-class free lists are disjoint and collectively cover all free pages; the generic-availability counter agrees with the count after excluding pin-only low pages. The PGR2 lists also have verified backward links.

Normal captured scene	BIOS	Available physical RAM	Generally allocatable RAM	Busy physical pages	Public stack pages
Conker animated bar menu	PR152 release64	2,208pages /8.625MiB	2,196pages /8.578125MiB	14,176	43
PGR2 red car parked at0MPH	Plain-main release64	1,388pages /5.421875MiB	1,376pages /5.375MiB	14,996	84

Each capture includes12 free pin-only low pages. Neither has free pages remaining in the kernel-preferred class; generic allocations can spill into the title class under the existing policy. That is not itself corruption or exhaustion.

These are two single post-window checkpoints with different titles and BIOS revisions, not a matched memory-saving comparison, low-water record or loading/gameplay peak. Busy pages include title allocations, hardware reservations and firmware. Public stack pages include title-created contexts; their difference cannot be assigned to removable firmware workers. Free-page totals do not establish contiguous allocation capacity. No Complex title checkpoint was recorded in this pair.

The measurements establish that the tested scenes run with several MiB of headroom. They do not prove that the remaining approximately0.7MiB reference footprint gap is harmless through every loading/save/gameplay transition. Size work should now prioritize usable capacity and peak pressure alongside actual resident ownership, rather than assume that1% of installed RAM means1% of remaining title headroom.

October 10: startup stalls resolved to actual callers and device context

The existing recordings were sliced without another broad performance campaign. SubtractLoop is the linked Xbox KeStallExecutionProcessor body in generic/systimer.S, not exclusively boot calibration. Conker's samples are predominantly within the first10 seconds. PGR2's samples cluster just after the first authored A; its first-A-to-final-release route attributes2.467% of sampled process periods to this loop. Neither percentage measures waiting or establishes a frame-time improvement.

Two isolated, bounded PGR2 guest-debugger captures then recorded the unchanged ordinary64 BIOS and clean emulator:

Capture	Direct title1us requests	ATA setup1us requests	Calibrated loop scale
128-call limit	119	9	257
64-call limit, device correlation	55	9	256

Existing NVNET events were enabled only during the second short capture interval and disabled successfully afterward. They record307 PHY status reads, all MII_BMSR=0x8,885 register reads and301 register writes, with no negotiation-start/done event in that interval. Link-up and negotiation-complete bits are absent. This supports offline network polling as the next producer/context investigation; it does not prove that every stall belongs to a specific PHY read or that the BIOS performs an unnecessary hardware wait.

Both sessions complete all unchanged inputs, end at the parked red-car start and exit normally. The boundary starts during the course flyover. Debugger and device-log latency perturbs execution, so these runs are excluded from performance comparisons. No title code or raw state is published. No firmware modification or speedup has been demonstrated.

Dedicated issue #157 requires a finite, independently timed short-stall fixture before a runtime change. A timestamp/deadline experiment must establish its own clock frequency; it cannot reinterpret the existing loop scale as TSC frequency. Required ATA/SMBus/PHY timing, high-IRQL operation, IF state, early boot and unavailable-host fallback remain explicit. Do not enable networking or alter the official PGR2 inputs to make this result disappear.

The ordinal151 reference has been corrected to the actual Xbox assembly route. The prior APIC-source reference described a HAL implementation that this build does not link.