Various sysctl cleanups #107
Conversation
This is already set by Arch via `/usr/lib/sysctl.d/10-arch.conf` from the `filesystem` package. Signed-off-by: Eric Naim <[email protected]>
According to [Arch Wiki](https://wiki.archlinux.org/title/Sysctl#Increase_the_maximum_connections) this only helps on high-loaded servers. Desktops won't become high-loaded servers ever probably, so on the basis of that knowledge remove this. If increasing this value does indeed has tangible benefits, I can revert this. Signed-off-by: Eric Naim <[email protected]>
There was a problem hiding this comment.
Guess I can't add further snippet reviews so I'll add it here
# This tunable is used to define when dirty data is old enough to be eligible for writeout by the
# kernel flusher threads. It is expressed in 100'ths of a second. Data which has been dirty
# in-memory for longer than this interval will be written out next time a flusher thread wakes up
# (Default is 3000).
#vm.dirty_expire_centisecs = 3000
We are also not setting this.
# Only experimental!
# Let Realtime tasks run as long they need
# sched: RT throttling activated
kernel.sched_rt_runtime_us=-1
I'm skeptical about this, maybe we can set it to a higher predefined value than the default instead?
| # The value controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects (VFS cache). | ||
| # Lowering it from the default value of 100 makes the kernel less inclined to reclaim VFS cache (do not set it to 0, this may produce out-of-memory conditions) | ||
| #vm.vfs_cache_pressure=50 |
There was a problem hiding this comment.
Do we want to set this? If not we should just remove it.
There was a problem hiding this comment.
AFAIK we used to have a patch that increased this value in our kernel. Not sure how things are now.
There was a problem hiding this comment.
CachyOS/linux@9fa4ce3 Doesn't seem to be the case now. On another note, we need to rework these tweaks.
There was a problem hiding this comment.
What's the consensus of this? I haven't really read much about this so I'm still not too sure about what impacts a lower value might have compared to the default. Is it worth setting this?
There was a problem hiding this comment.
Honestly, I'd like to leave it uncommented since we don't have a patch to change it right now, but it's a quite useful tweak, I've been writing more details about it: https://ventureo-codeberg-page.translate.goog/source/kernel-tuning.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp#vfs
1Naim
force-pushed
the
chore/sysctl-cleanup
branch
from
de0950d
to
2045833
Compare
We already have this set in the kernel, and having a duplicate here can cause instances when users want to test the default algorithm in another kernel, but will still have BBR set. Signed-off-by: Eric Naim <[email protected]>
Currently there seems to be a bit of a redundancy in the settings set here, so I'd like to clean it up a bit. There are also some removals/tweaks to settings that don't make quite sense to me (based on my limited knowledge), so I've opted to removed them in the PR, but I am very open for discussion.