threads-max is the maximum number of threads that the kernel can use at one time throughout the system The kernel parameter to set. The value that can be set for this parameter is significantly higher than MAX_THREADS. Until recently, there was a regression that only small values could be set. Specifically, from kernel-4.0 (April 2015) to kernel-5.4-rc3 (October 2019) Such a situation continued. This has been fixed in kernel-5.4.
Old-fashioned behavior (tested in 4GB RAM environment) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823
kernel with regression (tested in 4GB RAM environment) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 31348
The upper limit that can be set in the kernel is automatically set according to the size of the real memory. It was a noisy operation that made me decide. If the application does not adjust this parameter It would have been a problem in an environment where it couldn't work.
An email like this was sent to LKML and the discussion started. .. .. .. 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.
Free translation: "My customer rewrites the value entered by threads-max with auto tuning working. I found it working, but what does patch 16db3d3f1170 mean? "
Developer replies 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.
Free translation: set_max_threads () limits the thread limit to 1/8 of RAM. It's no longer possible for the system to stall by filling memory with thread data!
SUSE engineers answer and say 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.
Free translation: That's what the administrator decides. That's why there are measurement tools like memcg.
You do not change the software to overcome artificial bounds based on guessing.
Free translation: Do not make any changes that set an upper limit by arbitrary guess.
Another engineer 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).
Free translation: The behavior that hasn't changed since 2.6.12-rc2, which I started managing with git, has changed due to the patch.
Limiting threads_max to the auto-scaling value is a regression.
Free translation: It is Regression that adjusts the input value of threads-max to auto-scaling value.
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")
Free translation: We propose to revert the patch.
Andrew Morton comes out and says a word https://lkml.org/lkml/2019/9/19/748 I agree, based on what I'm seeing in this thread.
Free translation: I saw this thread, but I agree with reverting.
Thus, b0f53dbc4bc4c371f38 (kernel / sysctl.c: do not override max_s A patch called provided by userspace) has entered the mainline kernel The patch was backported to the stable relase below.
Mainline 5.4 stable 5.3.7 stable 4.19.80 stable 4.14.150 stable 4.9.197 stable 4.4.197
In these kernel versions, # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823 It has returned to the old operation.
With the patch backported to Stable relase, the Fedora 31 kernel also has a thread-max fix.
that's all
Recommended Posts