![slub_min_objects :为什么 0 可以作为有效/默认值/基本原理?](https://linux22.com/image/190237/slub_min_objects%20%EF%BC%9A%E4%B8%BA%E4%BB%80%E4%B9%88%200%20%E5%8F%AF%E4%BB%A5%E4%BD%9C%E4%B8%BA%E6%9C%89%E6%95%88%2F%E9%BB%98%E8%AE%A4%E5%80%BC%2F%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%EF%BC%9F.png)
mm/slub.c
在我的linux_5.4内核的源代码()的注释中,我可以读到:
In order to reach satisfactory performance we must ensure that a minimum
number of objects is in one slab. Otherwise we may generate too much
activity on the partial lists which requires taking the list_lock. This is
less a concern for large slabs though which are rarely used.
我的理解“最少数量的物体”是无论什么> 0
从某些 linux-4 下实现的一些基准测试中,我什至了解到最佳值是 2 * CPU 数量。
在文档(Documentation/vm/slub.rst)中我可以阅读:
.. slub_min_objects=x (默认 4)
拥有 2 个核心,我对这个默认值感到满意。然而,我的引导日志告诉我们:
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
当然,我可以将其设置slub_min_objects=4
为启动命令行的一部分并成功获得 MinObjects=4。但是,我想了解默认值如何降至 0 ?
Linux 内核中的其他地方是否发生了变化,证明 0 实际上是最佳值?或者我们实际上不应该再关心这个作为更好表现的条件?
更新1:继@Paul_Pedant 的第一条评论之后
引导日志中的跟踪似乎是以下指令的结果:
pr_info("SLUB: HWalign=%d, Order=%u-%u, MinObjects=%u, CPUs=%u, Nodes=%u\n",cache_line_size(),slub_min_order, slub_max_order, slub_min_objects,nr_cpu_ids, nr_node_ids);
slub_min_order 设置如下:
get_option(&str, (int *)&slub_min_objects);
这显然证实了 Paul_Pedant 的猜测:“引导日志正在报告用户提供的值”
以下代码可能会说明实际使用的表示最小对象数量的值:
min_objects = slub_min_objects;
if (!min_objects)
min_objects = 4 * (fls(nr_cpu_ids) + 1);
也就是说,要么是启动命令行参数,要么是基于 cpu 数量的默认值。在我的例子中(2个cpu,最高有效设置位的位置= 2):
最小对象数=4*(2+1)=12
4 <= CPU < 8 的默认值为 16,8
<= CPU < 16 的默认值为 20
顺便说一句,记录的默认值 4 可能来自单处理器系统。
如果我能找到缩放背后的一些基本原理,这个问题就可以说是结束了。