threads-maxはシステム全体でカーネルが一度に使用できるスレッドの最大数を
設定するkernel parameterです。
このパラメータに設定できる値が、MAX_THREADS よりも大幅に
小さな値しか設定できないというregressionが最近までありました。
具体的には kernel-4.0 (2015年4月）から kernel-5.4-rc3 (2019年10月）までの間、
そのような状況が続いていました。
これは kernel-5.4 で修正されました。
昔からの動作 (4GB RAM環境でテスト)
# echo 0x3fffffff > /proc/sys/vm/threads-max
# cat /proc/sys/vm/threads-max
1073741823
regressionありのkernel (4GB RAM環境でテスト)
# echo 0x3fffffff > /proc/sys/vm/threads-max
# cat /proc/sys/vm/threads-max
31348
実メモリのサイズに合わせて、kernelに設定できる上限値を自動的に
決めてくれるようなお節介な動作となりました。
アプリケーションがこのパラメータを調整しないと
動作できないような環境では問題となった事でしょう。
LKMLにこんなメールが流れてきて議論が始まりました。。。。
https://lkml.org/lkml/2019/9/17/294
Hi,
I have just stmbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max
observe limits") and I am really wondering what is the motivation behind
the patch. We've had a customer noticing the threads_max autoscaling
differences btween 3.12 and 4.4 kernels and wanted to override the auto
tuning from the userspace, just to find out that this is not possible.
Why do we override user admin like that? I find it quite dubious to be
honest. Especially when the auto-tunning is just a very rough estimation
and it seems quite arbitrary.
意訳：「うちのお客が threads-max が auto tuningが働いて入力した値を書き換える
動作を見つけたんだけど、パッチ16db3d3f1170 って何を意図しているんだ?」
開発者返答して曰く
https://lkml.org/lkml/2019/9/17/570
set_max_threads() sets the upper limit (max_threads_suggested) for
threads such that at a maximum 1/8th of the total memory can be occupied
by the thread's administrative data (of size THREADS_SIZE). On my 32 GiB
system this results in 254313 threads.
With patch 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
a user cannot set an arbitrarily high number for
/proc/sys/kernel/threads-max which could lead to a system stalling
because the thread headers occupy all the memory.
意訳: set_max_threads()が threadの上限値をRAMの8分の1に制限してくれるから、
メモリをthreadのデータで埋め尽くしてシステムがストールするようなことは起こらなくなったよ!
SUSEのエンジニアが答えて曰く
https://lkml.org/lkml/2019/9/17/589
This is still a decision of the admin to make. You can consume the
memory by other means and that is why we have measures in place. E.g.
memcg accounting.
意訳:そんなもの、管理者が決めることだろ。
そのためにmemcgのような計測ツールがあるわけだし。
You do not change the software to overcome artificial bounds based on
guessing.
意訳: 勝手な推測で上限値を設けるような変更を入れないでください。
別なエンジニアが
https://lkml.org/lkml/2019/9/17/705
a) The logic to set the default number of threads in a system
has not changed since 2.6.12-rc2 (the start of the git history).
意訳: gitで管理を始めた2.6.12-rc2から変わってなかった動作がパッチにより変わった
Limiting threads_max to the auto-scaling value is a regression.
意訳: threads-max の入力値を auto-scaling value に調整するのは Regressionだな。
https://lkml.org/lkml/2019/9/19/113
Any take on this Heinrich? If there really is not strong reasoning about
the restricting user input then I will suggest reverting 16db3d3f1170
("kernel/sysctl.c: threads-max observe limits")
意訳：該当パッチをリバートすることを提案する。
Andrew Morton出てきて一言
https://lkml.org/lkml/2019/9/19/748
I agree, based on what I'm seeing in this thread.
意訳： このスレッドを見てたけど、リバートするのは賛成。
こうして、b0f53dbc4bc4c371f38(kernel/sysctl.c: do not override max_threads provided by userspace) というパッチがメインライン kernel に入り、
そのパッチが以下のstable relase にバックポートされていきました。
Mainline 5.4
stable 5.3.7
stable 4.19.80
stable 4.14.150
stable 4.9.197
stable 4.4.197
これらのkernel versionでは、
# echo 0x3fffffff > /proc/sys/vm/threads-max
# cat /proc/sys/vm/threads-max
1073741823
という昔からの動作に戻りました。
Stable relaseにパッチがバックポートされたことで、Fedora 31のkernelにも threads-maxの修正が入りました。
以上