| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
test/linux-all-prs-plus
# Conflicts:
# src/common/host_memory.h
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4219
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3133
Reviewed-by: DraVee <dravee@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This formats all copyright comments according to SPDX formatting guidelines.
Additionally, this resolves the remaining GPLv2 only licensed files by relicensing them to GPLv2.0-or-later.
|
| |
|
|
|
|
| |
This falls back to the old approach of using a virtual buffer.
Windows is untested, but this build should fix support for Windows < 10 v1803. However without fastmem support at all.
|
| |
|
|
|
| |
In theory, if we have 2 MB continously mapped, this should save one layer of TLB.
Let's make it at least more likely by aligning the memory.
|
| |
|
