eglantine-cirakg/src/common/host_memory.h, branch nx2

Merge remote-tracking branch 'origin/fix/memory-skip-zero-clears' into test/linux-all-prs-plus

2026-11-01T20:13:56+00:00

# Conflicts: # src/common/host_memory.h

texture_cache: mark guest memory textures were uploaded from cold

2026-11-01T13:48:31+00:00

Once a texture is uploaded the host GPU has its own copy, and the guest rarely reads that memory again, but it stayed in the emulator's working set. Every 600 frames the guest ranges of images uploaded since (64 KiB or more, not GPU-written or sparse) are marked cold through HostMemory::HintCold, backing and CPU view, from a low-priority worker, so the OS pages them out before anything else when it needs RAM. Their contents stay; using them brings them back. Mario Kart World's title screen at ~10 minutes: game memory in RAM 4.8-5.5 -> 3.6 GB, the emulator's real RAM 10.6-11.9 -> 9.4 GB, frames over 100 ms not worse. (cherry picked from commit ea36b2c5ca352f8c8cdcc829a2d3bde9bdc06ece)

nx2: let the host page out texture pool backing first

2026-10-31T05:32:04+00:00

Switch 2 sparse blocks and GPU-only regions get guest memory when a game writes them (Mario Kart World copies 2-4 GB of compressed textures into its sparse texture pools) and the texture cache reads it again only when it builds an image there. Every 30 s, mark that backing cold: its pages leave the working set (VirtualUnlock on Windows, MADV_PAGEOUT on Linux) so the OS compresses or pages them out before anything else when RAM is short. The contents stay. Mario Kart World: 8.5 GB of RAM in use at five minutes instead of 9.0 GB on a machine with RAM to spare, frame times unchanged.

memory: skip clearing guest memory that is still zero

2026-10-30T08:40:24+00:00

The kernel clears every page it hands out, and the backing memory is a page-file section the host only gives RAM to once a page is touched. So the clears themselves made every page of a game's heap resident: Mario Kart World (12 GB layout) had a 12.5 GB working set 20 s after boot. HostMemory keeps two bits per 64 KiB of backing: used (handed out by the kernel at least once) and dirty (may hold data). Pages returned to the kernel mark their granules dirty, and a zero clear only touches dirty granules; a granule cleared in full is clean again. A new kernel on the same memory marks everything a previous one used dirty, so leaked processes can't leak data into the next game. KMemoryManager's optimized-process fill and KSharedMemory's clear go through the same path. Mario Kart World, title screen and attract demo, 180 s: working set 20 s in 4.7-6.4 GB instead of 12.5 GB, peak 14-17.6 GB instead of 20.1 GB.

kernel: clear the fastmem arena when the application process is closed

2026-10-30T04:54:37+00:00

Loading a Switch 2 game after another one in the same window hung or crashed it at boot. The first game's process still had 55-60 references at kernel shutdown, so it was never finalized and its memory stayed mapped in the fastmem arena. The next game's mappings at the same addresses then failed ("Failed to split placeholder" / "Failed to map placeholder"), and it ran on the first game's memory: Mario Kart World loaded after another Switch 2 game jumped to a garbage address from rtld, or hung. Detach the closed process from the arena (a late finalize must not unmap the next game's memory), unmap the whole arena, and log when the process was still referenced.

kernel: clear the fastmem arena when the application process is closed

2026-10-30T04:54:09+00:00

[common/core/dynarmic] Optimize page table allocations (#4219)

2026-09-09T19:35:49+00:00

Reduces the page entries from 32 bytes to 8 and rewrites `VirtualBuffer` to be more efficient in memory usage and specifically for large zero regions. The page table will now only reserve 1GiB instead of 4GiB and of this memory it should only use at most ~8MiB. This PR has the side effect of using Eden on Windows on low memory systems much more plausible since it would previously require ~10GiB of committable memory at front (despite using ~5-6 at most, inadvertently stalling other processes) where as now it should only require around the amount that it'll actually use. Co-authored-by: Lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4219 Reviewed-by: Maufeat Reviewed-by: lizzie Reviewed-by: CamilleLaVey

[common] fallback to VirtualBuffer if we can't use file mappings (#4005)

2026-06-15T20:05:42+00:00

fixes: - windows 8.1 - windows 7 - managarm - openorbis Signed-off-by: lizzie lizzie@eden-emu.dev Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4005 Reviewed-by: MaranBr Reviewed-by: Maufeat

[host_memory] remove unused fastmem fallback path (#3133)

2026-01-13T01:06:35+00:00

basically nobody ever used that path, we instead soft-crash upon not being able to allocate **backing** storage, we do still attempt to allocate a virtual base through, but if backing storage fails for any reason whatsoever, we pretty much cant run the emulator anyways Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3133 Reviewed-by: DraVee Reviewed-by: CamilleLaVey Co-authored-by: lizzie Co-committed-by: lizzie

core: track separate heap allocation for linux

2023-12-26T04:30:56+00:00