search

CryoByte33 / steam-deck-utilities

A utility to improve performance and help manage storage on Steam Deck.
GNU General Public License v3.0
3.08k stars 79 forks source link

SteamOS 3.6..0 Preview uses zram, breaks CryoUtilities swap management #179

Open omor1 opened 2 months ago

omor1 commented 2 months ago

SteamOS 3.6.0 uses zram; since this has higher priority than the swap file, this breaks getSwapFileLocation.

It's a bit unclear to me if zram is being used instead of, or in addition to the swap file. This might also impact recommended swappiness: since swap is in compressed memory, it's much cheaper to write to/read from and it might mean it's better to proactively push less frequently used memory to zram.

CryoByte33 commented 2 months ago

Good catch, I haven't had the time to try 3.6 preview, but it was working on main just a month or 2 ago, so Valve must have made another change. I have an update nearly ready for CU so I'll try to batch this in.

As for swappiness, it shouldn't make that much of a difference since raw RAM and ZRAM will both operate at similar speeds, but ZRAM will benefit from additional compression. As long as the swap devices have the correct precedence, you should see similar performance, but as always I will have to test to make sure.

CryoByte33 commented 2 months ago

As an aside, I recently got a new job and have been very busy, sorry for what seems like no work on this project, I've just been doing a lot on a private testing repo since I made a lot of breaking changes :)

krozgrov commented 2 months ago

Does that mean to uninstall if upgrading to 3.6.0? Or can we keep cryo installed just knowing that zram is being used?

CryoByte33 commented 2 months ago

Does that mean to uninstall if upgrading to 3.6.0? Or can we keep cryo installed just knowing that zram is being used?

CU should still be safe on 3.6, just avoid the swap resize function until a permanent fix is out. Aside from that you should be set, to the best of my knowledge.

Aepoh commented 3 weeks ago

Came here to make this issue, glad to see someone else got to it first. image I don't really know what priority means, but I assume it relates to Swappiness. If that's the case and zram is being prioritized then it would probably break the Swappiness setting as well.

omor1 commented 3 weeks ago

I don't really know what priority means, but I assume it relates to Swappiness. If that's the case and zram is being prioritized then it would probably break the Swappiness setting as well.

Priority is used by the Linux kernel to determine where to swap out pages evicted from memory—it generally tries using higher-priority swap locations before lower-priority ones. In this case, it tries evicting pages into zram (compressed memory) before it uses the swap file.

It is entirely orthogonal to swappiness, which determines how proactive the kernel is about evicting pages from memory.

Aepoh commented 3 weeks ago

I don't really know what priority means, but I assume it relates to Swappiness. If that's the case and zram is being prioritized then it would probably break the Swappiness setting as well.

Priority is used by the Linux kernel to determine where to swap out pages evicted from memory—it generally tries using higher-priority swap locations before lower-priority ones. In this case, it tries evicting pages into zram (compressed memory) before it uses the swap file.

It is entirely orthogonal to swappiness, which determines how proactive the kernel is about evicting pages from memory.

Ok so not the same thing, gotcha. I wonder if having two page files like that is problematic. Like if we imagine the page files as buckets and the computer is dumping data into the first bucket and then needs to dump data into the second one because the first one is full, is that going to be a seamless process or will there be some hitching/slowdown/stutter involved?