tune swappiness

[protosam]

Needs validation to ensure it persists. I don't intend to mod my Steam Deck to test when /etc/sysctl.d/swappiness.conf is overwritten.

[CryoByte33]

Thanks for the PR! I just checked this and it looks like the entire /etc directory is overwritten every update 😞

Let's workshop an idea here before merging this, since I don't necessarily want to ask people to re-run my swap fix all the time.

My first thought was a systemd service on boot, but that gets overwritten too. Maybe we could make a separate optional script to "run after update if you want the best performance"? That would keep the ease of use, but allow more configurability.

Edit: I'm mainly worried about the unecessary writes each time someone wants to change their swappiness. We'd also need to disable the read-only filesystem for the swappiness setting, which I literally just removed from the main script 😅

[protosam]

Hmm.. If we made a flatpak people could install, would that persist?

The idea I have in mind is having a system daemon in a flatpak that would only run once on boot. It could use a script or something like ansible to validate and persist the system changes.

Sidenote, I currently don't know much about flatpaks. What's the tldr on how they're isolate and persisted?

[CryoByte33]

The flatpak itself would persist, but the changes it makes are sandboxed. You can allow it access over other parts of the system (EmuDeck does this), but changes to /etc would still be overwritten.It also seems that while flatpaks can be run as a systemd service, I can't see a way to have them install one.

I think the other caveat of a flatpak is that, because of its sandboxed nature, we wouldn't be able to affect the system at large without having users run commands to un-sandbox it. That's actually why I went with a simple bash script to begin with.

My first 2 thoughts right now are:

1. I'm not immediately aware of a way to do it, but the hassle of running these scripts could be alleviated by having them run in SteamOS mode as a non-steam game. Users could just run it again right after an update.
2. I have no idea what the privilege level of Decky plugins are, but I know that they can hook into the render pipeline at least. If that's the case then we may be able to make a plugin that can set the swappiness, enable and disable TRIM, etc.

I'm heading to bed now, but I'll try to give these a look in the next few days as time allows 🤔

[protosam]

Let me circle back to this. I need to set aside some time to see how SteamOS is built and delivered; also need to investigate flatpaks.

My thought process right now is as follows. There's pros and cons... and I'm clearly an autist.

1. Relying on Decky would offload the effort of persisting the changes to homies maintaining Decky; but I have reservations about blindly trusting it after the types of issues I saw posted about after the last Steam OS update.

2. While I don't agree with using the Steam Deck as a desktop, Valve did blatantly advertise it as a desktop PC. As such, I have a hard time believing they didn't provide some sane way for power users to persist system-wide changes. If they actually left us short here, I've got the type of isms where I'd like to fix the root problem in a way that fits industry standards.

[protosam]

My guess is that flatpaks are installed in /home/deck. If we can rely on ~/.bashrc, it might be a good place to start a script to reconcile the desired state from. Both gaming and desktop modes trigger ~/.bashrc.

I'm not sure if Decky Loader persists upgrades. It's installer uses /etc.

[CryoByte33]

Relying on Decky would offload the effort of persisting the changes to homies maintaining Decky; but I have reservations about blindly trusting it after the types of issues I saw posted about after the last Steam OS update.

This is definitely fair, it took me a few minutes to undo Decky nonsense, but there's no denying something with that amount of access could be an easy way to configure persistent settings.

While I don't agree with using the Steam Deck as a desktop, Valve did blatantly advertise it as a desktop PC. As such, I have a hard time believing they didn't provide some sane way for power users to persist system-wide changes. If they actually left us short here, I've got the type of isms where I'd like to fix the root problem in a way that fits industry standards.

I also have some -isms, so we can definitely band together and figure this out. While they definitely market it as a desktop, they also market it as "install what you want", and I'm not sure where in the "I want to configure this" process moving to a new OS is 😂

My guess is that flatpaks are installed in /home/deck. If we can rely on ~/.bashrc, it might be a good place to start a script to reconcile the desired state from. Both gaming and desktop modes trigger ~/.bashrc.

This is actually a really interesting idea, even if we don't use Flatpak .bashrc could be a good method of making sure it runs after upgrade. The only issue I can see is that modifying anything in /etc will require sudo and we might not have a good way to display a prompt when needed, particularly in game mode.

---

Looking into other options, I came across SteamDeckPersistentRootFS but am definitely not a fan since it requires tons of manual steps and has a high rate of failure.

Then, I came across this tips repo and see that while /etc does get wiped after upgrades, some things get offloaded to /home and placed back in there apparently. I'll need to dig into exactly what this happens to and if third-party files take precedence over Valve-created ones.

The downside is that since I'm making YT videos and only have a single Deck to test with, my ability to workshop fixes will be limited for most of the week, especially if I don't want to accidentally pollute some tests with random swappiness values and whatnot. 😅

[popsUlfr]

I came across this pull request and just wanted to add my 2 cents about /etc:

Basically OverlayFS is used to layer a read-write layer on top of the read-only rootfs for /etc. Any changes you make in /etc will be stored at /var/lib/overlays/etc/upper where /var is mounted from one of two additional ext4 partitions for variable data (/dev/nvme0n1p6 or /dev/nvme0n1p7). Which one is used directly corresponds to the rootfs slot currently used (/dev/nvme0n1p4 with /dev/nvme0n1p6, /dev/nvme0n1p5 with /dev/nvme0n1p7). There are a couple of directories in /var that also use the overlayfs layering mechanism, the read-write layers mostly pulled from the home partition (/dev/nvme0n1p8). The /etc read-write layer however is definitely stored in one of the two var partitions. So, as long as those partitions are not wiped any changes will persist through updates.

In this specific case of changing the swappiness I would strongly suggest to not modify the existing /etc/sysctl.d/swappiness.conf which is shipped in the read-only rootfs but instead to create a new file like /etc/sysctl.d/zzz-swappiness.conf by leveraging the lexical order of loading. Modifying existing files from the rootfs, will shadow any changes made in the underlying layer.

[CryoByte33]

@popsUlfr Thank you for the clarification on the /etc behaviour, that'll save me a decent chunk of research.

In this specific case of changing the swappiness I would strongly suggest to not modify the existing /etc/sysctl.d/swappiness.conf which is shipped in the read-only rootfs but instead to create a new file like /etc/sysctl.d/zzz-swappiness.conf by leveraging the lexical order of loading. Modifying existing files from the rootfs, will shadow any changes made in the underlying layer.

I literally have /etc/sysctl.d/zzzz-custom-swappiness.conf on my deck to test that this very second 😂 Thank you for the hints, though!

[protosam]

Saw the overlayfs as well, but have very little trust until I can test it. I've been looking for a way to force update behavior to repeatedly test changes. If anyone has a suggestion for that, please let me know.

[popsUlfr]

Saw the overlayfs as well, but have very little trust until I can test it. I've been looking for a way to force update behavior to repeatedly test changes. If anyone has a suggestion for that, please let me know.

What do you mean by this ? If you are talking about applying sysctl settings from newly added config files you can just do sysctl --system. But anything you store in /etc will persist through updates. In the Btrfs project for instance, there's a config file in /etc that users can edit to change the default options (default fs for sd card formats, mount options, extra arch packages to install into the rootfs, etc...) and it makes sure the user settings are kept through updates. Also, since I patch sensitive system files like /etc/fstab, I also need to take into account the potential existence of this file in the upper layer (custom mount points for instance) which shadows the lower one so I apply the same modifications there too if needed. If any modifications are made to the upper overlay layer (here in /var/lib/overlays/etc/upper) (or the lower layer) the kernel needs to be made aware of this or the changes will not reflect in /etc or lead to corrupted listings, a simple mount -o remount /etc handles this. This a specific need and is not needed of course when saving into /etc directly (the changes are maintained by overlayfs in /var/lib/overlays/etc/upper).

[CryoByte33]

@protosam I just refactored your code and did some general improvements in this branch if you want to check it out.

I tested it pretty thoroughly, but if you feel like trying it wouldn't hurt. I'm going to merge the changes to master when my next video goes live.