Skip to content
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

Cleanup options (part 1) #388

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Cleanup options (part 1) #388

wants to merge 2 commits into from

Conversation

ventureoo
Copy link
Member

We've talked about this before in #367, and this time I've limited myself to removing options that won't cause doubt.

First commit removes _makegconfig and _makemenuconfig:

We have 4 interfaces for kernel configuration, most of which have the
same functionality and differ only in the rendering backend. gconfig
uses GTK2 which is EOL, and unlikely anyone will install it just for
gconfig when there are alternatives like xconfig which is based on Qt5 /
Qt 6. Similarly in the case of TUI, instead of menuconfig, here we have
ncurses based nconfig which is supported by most terminals.

Second commit removes _NUMAdisable:

The first reports of positive impact of disabling NUMA for desktop
systems date back to 2012 [1], and even then they were extremely minor
and at margin of error level of ~300ms at kernel compilation. Now more
than 10 years have passed, there have been many NUMA-related changes in
kernel over the years and it probably makes no sense to say that
disabling NUMA provides any benefits. I haven't found any relevant
performance comparisons with NUMA disabled, if someone provides them and
shows evidence that it may still be necessary - I'm happy to revert this
change.

I should also note that some schedulers like PDS and BMQ forcibly
disable NUMA because they do not have a proper implementation of its
support.

[1] - https://bugs.archlinux.org/task/31187

I should add that NUMA can also be disabled during the boot time via numa=off.

We have 4 interfaces for kernel configuration, most of which have the
same functionality and differ only in the rendering backend. gconfig
uses GTK2 which is EOL, and unlikely anyone will install it just for
gconfig when there are alternatives like xconfig which is based on Qt5 /
Qt 6. Similarly in the case of TUI, instead of menuconfig, here we have
ncurses based nconfig which is supported by most terminals.

Signed-off-by: Vasiliy Stelmachenok <ventureo@cachyos.org>
The first reports of positive impact of disabling NUMA for desktop
systems date back to 2012 [1], and even then they were extremely minor
and at margin of error level of ~300ms at kernel compilation. Now more
than 10 years have passed, there have been many NUMA-related changes in
kernel over the years and it probably makes no sense to say that
disabling NUMA provides any benefits. I haven't found any relevant
performance comparisons with NUMA disabled, if someone provides them and
shows evidence that it may still be necessary - I'm happy to revert this
change.

I should also note that some schedulers like PDS and BMQ forcibly
disable NUMA because they do not have a proper implementation of its
support.

[1] - https://bugs.archlinux.org/task/31187

Signed-off-by: Vasiliy Stelmachenok <ventureo@cachyos.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant