-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various sysctl cleanups #107
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to set this? If not we should just remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CachyOS/linux@9fa4ce3 Doesn't seem to be the case now. On another note, we need to rework these tweaks.
@@ -49,10 +44,6 @@ kernel.kptr_restrict = 2 | |||
# Disable Kexec, which allows replacing the current running kernel. | |||
kernel.kexec_load_disabled = 1 | |||
|
|||
# Increase the maximum connections | |||
# The upper limit on how many connections the kernel will accept (default 4096 since kernel version 5.6): | |||
net.core.somaxconn = 8192 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My opinion is that 8192 is overkill for any user that is not hosting a decently sized server, or idk a database. maybe we could hardcode "8192" for the server kernel variant and leave "4096" which is the current default value in Linux therefore removing or commenting this sysctl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we could hardcode "8192" for the server kernel variant
If we want to do this, we need to do something like
#ifdef CONFIG_CACHY
#define <max_connections> 4096
#else
#define <max_connections> 8192
We don't have a specific config for the server kernel, it is currently just CONFIG_CACHY=n
, but even then I think the default 4096 should work fine already for servers.
de0950d
to
2045833
Compare
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.