您可以轻松地更改内核参数sysctl，然后使其持久化/etc/sysctl.d但是有没有一种快速的方法来更改默认内核参数，例如默认值虚拟机交换性 = 60在内核编译阶段。
我发现在内核源代码中有例如。毫米/vmscan.c文件，里面有：
(...)
int vm_swappiness = 60
(...)
参数，但这是修改许多源文件中存在的这些参数并更改它们的正确方法，还是有可能创建一些我想要更改的用户文件？模块也是如此。我是否需要编辑模块源文件以向我的模块添加/更改一个选项，如/etc/modprobe.d：
options modulename parameter=value
总结一下，我想在编译阶段更改一些内核默认参数和一些模块选项。
答案1
关于实际上可以通过 sysctl 设置调整的内核参数，我几乎看不到通过修补内核源代码来修改这些值的任何兴趣。
您需要在下一个内核更新时重做工作，如果您执行补丁，则需要确保您的补丁正确应用：杀戮过度实际上只不过是设置一些不同的默认值！
关于永远不会暴露给用户空间的硬编码值，人们可能普遍认为修改它们肯定没有兴趣（或者存在高风险）。并不是说您需要深入了解对依赖它的所有其他参数的影响。这可能吗 ？我想说，除非您是相关内核源代码的积极贡献者：不！
然而，对于不一定暴露给用户空间的内核可调参数，我们可以发现这样做有一些兴趣取决于内核的配置选项。
让我们以调度程序可调参数为例，例如sched_latency_ns仅当设置了 CONFIG_SCHED_DEBUG 时才会暴露给用户空间。
使用此配置设置会产生开销。
然后，从逻辑上可以看出，希望减少延迟并接受调度程序处理中的开销是不一致的。
在这种非常特殊的情况下，禁用调试代码并对值进行硬编码可能会显得一致，因为它成为更改数据的唯一可能的方法。
当然，您意识到，以这种方式执行操作，您很可能会强制使用内核尚未经过测试的值，并且可能会破坏这些值，从而使您无法进行调试。 （关于上面的例子......你实际上可以得到令人讨厌的结果玩sched_wakeup_grinderity_ns值。）
当然，您意识到下次更新内核时，您需要重做所有工作，并且必须了解设置在内核更改时的影响，这意味着对内核有非常深入的了解，并且，至少仔细阅读变更日志。
所以，“修改内核参数是否正确”？我会说…除非您之前确实使用通过专用内核调试功能支持的专用 sysctl 方式设置的那些可调参数来广泛测试您的系统：不！当然不 ！就连莱纳斯本人也不会这么做。
除此之外，加上我的个人经验，我必须承认，由于遵循了有关调度程序可调参数的方式（禁用调试代码和杂项统计），我刚刚发现自己有 0 个可用数据来客观地确认或证实我的摆弄的相关性......