我实际上可以想象两个位置:
- 在属于正在换入/换出内存的进程的内核空间中
- 从
[kswapd0]
然而,深入研究 kswapd 源代码(mm/vmscan.c
,init/main.c
),我可以发现:kswapd 是单线程的,并且是在单个线程上启动的。 (除了 NUMA 系统外,所有内存区域都有不同的 kswapd。但大多数普通 PC 都不是 NUMA 系统。)
然而,从现在开始我们有一个问题。我们可以假设,磁盘比内存慢得多,这就是为什么我们不需要多线程 kswapd 来处理磁盘 I/O。但如果我们还需要利用内部 zswap 层,情况就不是这样了。特别是在更强的压缩率(deflate)下,CPU 可能并且很可能会成为瓶颈。
但kswapd是单线程的。
这是真的吗?
是否计划使用多线程 kswapd?真的需要吗?
PS我发现了这Linux 内核邮件列表上的线程。这是关于一个被拒绝的补丁建议,什么可以在非 NUMA 系统上启用多线程 kswapd。他们什么都在谈论,除了这个 zswap 问题。也许是无关的。
PS2。语境:
- 我有一个内存严重过度使用的 Linux 系统(进程使用的内存远多于物理上可用的内存)。
- 同时运行的进程数远低于CPU核心数。
- 我正在大量使用 zswap。
- 在这种环境下,使用用于压缩/解压缩内存页的所有可用 CPU 内核。我目前最好的估计是页面压缩/解压缩是由
[kswapd0]
单个内核线程完成的。我正在研究利用所有 CPU 核心进行压缩/解压缩的选项。从本质上讲,这将是一种转换剩余 CPU 容量以弥补物理内存不足的方法。
答案1
经过大量调查后,我想我找到了答案。
实际的压缩是在[kswapd]
.
拒绝邮件的作者引用的线程表明负责人至少有某种原因他没有沟通,但更有可能的是他根本不知道 zswap 的情况。
我在我的系统上安装了补丁建议。它是kswapd
多线程的,即它可以压缩所有CPU核心上的内存。该补丁的作用就像魅力一样,并且对 zswap-ping 环境产生了显着的改善。
证据:我的系统(具有大量内存消耗的 qemu + pxz 压缩器)严重超载,包括内存和 CPU。之后,我在以下位置看到了这一点top
:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
927 root 20 0 12,3g 3,6g 3612 R 141,8 23,1 36006:53 qemu-system-x86
5017 root 20 0 7607428 4,2g 1580 R 78,4 26,8 2:32.85 pxz
354 root 20 0 0 0 0 R 53,6 0,0 32:17.28 kswapd0:5
128 root 20 0 0 0 0 R 45,8 0,0 32:57.42 kswapd0:0
352 root 20 0 0 0 0 R 40,5 0,0 32:16.80 kswapd0:3
356 root 20 0 0 0 0 R 36,6 0,0 32:53.58 kswapd0:7
350 root 20 0 0 0 0 R 35,3 0,0 31:15.53 kswapd0:1
353 root 20 0 0 0 0 R 35,3 0,0 30:48.00 kswapd0:4
351 root 20 0 0 0 0 R 28,1 0,0 31:57.45 kswapd0:2
355 root 20 0 0 0 0 R 27,5 0,0 31:44.12 kswapd0:6
是的,它还有以下含义:
- 多线程kswapd极大地提高了 zswap 性能,
- 它不包含在主线内核中,
- 是的,这可能是因为无能或担心不稳定。
我在测试环境中使用的 zswap 参数如下(可以在 中设置/sys/modules/zswap/parameters
):
same_filled_pages_enabled:Y
enabled:Y
max_pool_percent:50
compressor:deflate
zpool:z3fold
accept_threshold_percent:90