Issue in swap usage

[A404M]

After using linux-zen kernel for more than a year I realized that my system uses swap not in order that is optimized in any way. I realized that my ram usage is always around 69% (yes I'm curious and that's funny) that was because when my ram gets around 50% usage the kernel will start using swappiness and when it gets to 69% nearly all other allocations would move some pages to swap until my swap gets nearly full and the kernel will fill ram again, but my swappiness was 1 and no matter value value it has, the kernel will always do that. And as soon as I switched to vanilla linux kernel the problem went away. I wonder if this functionality is intended or not? I use the latest version of both kernels which comes in arch Linux repositories Because I use linux-zen because waydroid only works with kernels which come with binder modules and linux-zen has it. Thanks for your great efforts

[damentz]

Is this impacting the responsiveness of your system? Using swap in and of itself is not a problem unless it's actively causing issues with running applications.

We have some patches in our zen-sauce branch that affect swappiness. For the most part, proactive compaction and other aggressive reclaim/compaction behavior is disabled since it disrupts foregrounds tasks too much under memory pressure. What you're seeing instead is that memory is pushed to swap preemptively as a side effect.

[heftig]

I do wonder what causes the ZEN kernel to swap so aggressively even with its default settings and plenty of unused RAM.

               total        used        free      shared     buffers       cache   available
Mem:             29G        8.7G         14G        127M        106K        6.6G         20G
Swap:            10G        2.3G        8.4G
Total:           39G         11G         22G

Though I don't remember how the vanilla kernel behaves.

[A404M]

Is this impacting the responsiveness of your system? Using swap in and of itself is not a problem unless it's actively causing issues with running applications.

We have some patches in our zen-sauce branch that affect swappiness. For the most part, proactive compaction and other aggressive reclaim/compaction behavior is disabled since it disrupts foregrounds tasks too much under memory pressure. What you're seeing instead is that memory is pushed to swap preemptively as a side effect.

Yes it does actually affect my system responsiveness a lot Because I use 4 or 5 apps in foreground apps at the same time I have more than enough RAM for them (16GB but the apps are not that heavy) but It does move my active memory to swap and that hurts performance in my case I have been in Linux vanilla kernel after posting the issue till now and I really like it, the performance is much better here even when my whole ram and swap gets filled up

[damentz]

There's a few commits that could be the problem:

1. https://github.com/zen-kernel/zen-kernel/commit/f61fea137cc64dc793ac3939a3f5eec5a7584951 - patches from https://github.com/kerneltoast to tame the memory subsystem. They fixed real issues I was running into where as memory pressure increased, foreground applications would stall while compaction executed. I think now what we're seeing is instead of compacting, pages are tossed into swap to be handled later.
2. https://github.com/zen-kernel/zen-kernel/commit/e33a55b58006b8c58d478f8cdfcce297e736a1d8 - disabling compaction of unevictable pages, possibly could be related? This follows guidance from adjustments when PREEMPT_RT is turned on in ifdef macros. Restore with sudo sysctl -w vm.compact_unevictable_allowed=1
3. https://github.com/zen-kernel/zen-kernel/commit/47aa9995d6c9877a946f407137417521cc6a9963 - proactive compaction causes stalls in foreground applications if set too aggressive. Even at light settings I had problems with it so we use kerneltoast's patch. You can restore the default with sudo sysctl -w vm.compaction_proactiveness=20.
4. https://github.com/zen-kernel/zen-kernel/commit/627d13a7efb4d9ee1ac282017d0fcb5952b9108a - disabling watermark boosting is similar in effect of disabling proactive compaction. Restore to default with sudo sysctl -w vm.watermark_boost_factor=15000
5. https://github.com/zen-kernel/zen-kernel/commit/1b4743e952cfd1fa00e7c438d7e61ed18f5c5800 - protecting cache of data accessed in the last second, probably not related but you can tune in the value in /sys/kernel/mm/lru_gen/min_ttl_ms and restore it to 0 for testing.

@A404M would you be able to try testing the tunables to see if they're related? Worst case it's the first commit I mentioned. Speaking of which, we've been rebasing these patches for a while now, might be worth seeing if anything has changed in kerneltoast's current branch: https://github.com/kerneltoast/kernel_x86_laptop/commits/v6.10-sultan/